Changing default version constraints for magic

A long time ago, the Python community decided that we should use SemVer as the default versioning system. This was a great idea because it allows us to explicitly indicate when something will be broken in the next release.

However, not everyone uses SemVer. For example, pip uses the year as the first number in its versioning. MAX and mojo also use the year as the first number.

So, when we run magic add max and magic add --pypi pip, it locks the versions to the current year:

[pypi-dependencies]
pip = ">=24.3.1, <25"

[dependencies]
max = ">=24.6.0,<25"

By the way, uv uses more user-friendly rules:

dependencies = [
    "pip>=24.3.1",
]

Maybe magic should also switch from >=,< (equivalent to ^) to just >=? There is no need to follow SemVer rules in a package manager when the main package is not using SemVer. This change would help avoid additional headaches when using the magic upgrade command.

1 Like

I did bring up the following with Chris Lattner

And he responded that the fact that mojo and MAX ended up on 24 was a coincidence and not related to the year.

[Edit: Not exactly sure where the misfire occurred on that one, maybe it was month /shrug… (see below)]

The SemVer formatting comes from upstream pixilink.

Part of the idea of magic is to align with the greater programming community at large i.e. while MAX+mojo is the main package of Modular, you can use magic for a variety of non-mojo languages and environments as well.

Still, this is good feedback. If we just carry over all the cruft without considering whether it’s a good idea or not, then we’re doing double damage. And to your main comment about switching, what kind of scenarios can you see where magic upgrade could cause problems?

I don’t recall our previous discussion, but the “24” in “24.1” (etc) is indeed a year. Our next planned MAX release will be “25.1”. We’re not using semver for MAX releases because there are multiple different components with multiple different stability guarantees. MAX is more like “ubuntu” a distribution of linux that includes many packages, than it is like a single package.

1 Like

For example, I can develop a package that uses the version MAX==24.MAJOR.MINOR, which was published on December 25. However, someone from the team may find an important security issue that needs to be fixed ASAP, but the fix is published in January. Now, the package will be MAX==25.MAJOR.MINOR, despite only a few changes being made.

Now, every developer who uses MAX will need to perform a “magic upgrade” to download the latest version with this hotfix. However, due to SemVer constraints and the year of release, this hotfix simply won’t be downloaded. This actually happened to me once with pip as a package and poetry as a package manager.

1 Like

Is magic going to be built 100% in mojo eventually? Would be pretty cool if we could customize our package manager names @ the command line. Now that would be magic :smirk: