Repository navigation
Keep mypy_extensions versioning in sync with main package #5592
Description
On the Arch user repository, we sometimes like to build packages targeting the repository master branch. I’ve been made aware that mypy now hard-depends on the extensions module. Since the Arch Linux packaging tools support building multiple packages from one repository, it would be convenient to produce both packages in tandem. However, the distribution built from the extensions tree of the master branch currently has a version that does not satisfy the dependency imposed by mypy.
Would it make sense to make it so that a from-git build of mypy_extensions satisfies the dependency of a from-git build of mypy proper?
Activity
ilevkivskyi commentedon Sep 9, 2018
@ethanhs Do you have any opinion on this? Any hidden downsides? (This sounds reasonable to me.)
emmatyping commentedon Sep 10, 2018
I think this would be nice, but I am a bit confused on the concrete proposal of how it would work? Would we modify the dependency to be
mypy_extensions>=0.4,<0.6? Would we change the mypy_extensions version to be exactly the same as mypy? What happens when we need to bump the mypy_extensions version? (I think there are cases where this gets complicated or weird).ikelos commentedon Oct 4, 2018
If the two versions can be bumped independently of each other, and they're seen as different packages by the packages themselves, perhaps they should live in separate repositories? Rather than trying to keep two packages in one repo, it seems as though this should now be moved to something like github.com/python/mypy_extensions, with proper releases and tarballs. I'm facing similar issues trying to package this for Gentoo...
msullivan commentedon Oct 10, 2018
I think we should probably spin off
mypy_extensionsinto its own repository.ikelos commentedon Oct 14, 2018
That would be very helpful, not least because of the confusion it's causing. The package is called
mypy extensionsbut is required bymypy, so not actually an extension but a required part of the operation ofmypy? A better name for what it does would resolve that and make it clearer why it's separate. It should make it easier to justify why it's in its own package, and help answer questions as to what other packages would need this code that don't need the rest of mypy?We're also in the situation where it's a pre-release but is depended upon by a full-release version of
mypy, which as issue #5763 is showing, can lead to problems where the tarball formypyisn't actually suitable for installation.ilevkivskyi commentedon Oct 14, 2018
The name actually means something like "mypy-specific extensions to typing module". I have no preference regarding where to keep it.
ikelos commentedon Oct 14, 2018
Ok, I see, that does somewhat explain what it does and why it might be used separately (I don't know what a better name would be, but the package name alone suggests it's an extension of
mypy, perhapsmypy_type_extensions, unless that's cumbersome?). If it's independent ofmypyitself (ie, it could get installed without the need for the rest ofmypy) then probably a separate repo would be best, otherwise rolling it back into mypy so that it's not versioned independently seems like a better option, even if the code doesn't change much/at all between releases.msullivan commentedon Oct 16, 2018
It can indeed be installed without needing the rest of mypy, since it is the runtime support for some mypy extensions. Programs that use them (like mypy) will need
mypy_extensionsinstalled in order to run, while they only need mypy installed if you want to typecheck them.(Unless they avoid actually importing
mypy_extensionsat runtime by usingif MYPY, which maybe we could save ourselves some headaches by doing ourselves. (Though we use the@traitdecorator, which would be kind of annoying to handle this way.))ikelos commentedon Oct 16, 2018
Ok, cool. Then it sounds like it really is its own standalone package, and having it as a separate repository seems to make the most sense. It should make packaging much simpler than only distributing it as part of a mypy release too... 5:)
ikelos commentedon Dec 4, 2018
There seems to have been no progress on this in the month and a half since it was discussed. Has there been any further conclusion on this, so that the tarballs being shipped don't have conflicting versions of two packages which can't both be installed from the same tarball? I assume it's too late for 0.650, but it'd be good to consider how this will be resolved for package maintainers by 0.660...
msullivan commentedon Jan 15, 2019
OK, mypy_extensions has been split out into its own source project https://github.com/python/mypy_extensions. There are tags for 0.4.0 and 0.4.1 (which due to some sort of miscommunication, differ only by version number :P).
The extensions directory will be deleted in #6191.