Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New API in version 39? #1299

Closed
micahculpepper opened this issue Mar 17, 2018 · 2 comments
Closed

New API in version 39? #1299

micahculpepper opened this issue Mar 17, 2018 · 2 comments

Comments

@micahculpepper
Copy link

First of all, let me apologize if this was already explained somewhere else. My google-fu has failed me. If anyone can point me in the right direction, I'd appreciate it.

Today, I use pkg_resources.parse_version() to check if a package version number conforms to standards. Before v39, this returned a pkg_resources.SetuptoolsVersion object if the version number was fine, or a pkg_resources.SetuptoolsLegacyVersion if it was not fine.

In the version 39 release that just came out, it looks like pkg_resources.SetuptoolsLegacyVersion has moved to pkg_resources._vendor.packaging.version.LegacyVersion. The fact that it's now in _vendor makes me think that it's an internal namespace that I shouldn't be relying on.

Is there a recommended way for me to use setuptools to determine if a version number is valid? Setuptools is already doing that work, so I'd like to take advantage of the existing library, but it seems like now it's not intended for general use?

@jaraco
Copy link
Member

jaraco commented Mar 17, 2018

Great question. And good instincts. The good news is you can still rely on Version and LegacyVersion from the packaging.version packages, and the fact that the class is coming from the _vendor package is just an artifact of how Setuptools gets packaging. It can't depend on packaging and thus has to vendor it (due to #581).

So the best recommendation, if you wish to determine if a version number is valid, is to use the packaging. But you're also welcome to use the result from pkg_resources.parse_version.

If you wish for packaging.version to be the same class as the one returned by pkg_resources.parse_version, that's a little more difficult, but you can delete the packages in pkg_resources._vendor and pkg_resources will use packaging as installed. I wouldn't recommend that except in specialized cases where you know what you're doing.

Does that help?

@jaraco
Copy link
Member

jaraco commented Mar 18, 2018

Re-reading your question and thinking about it some more, here's what I recommend.

The most direct and best way to determine if a version number is valid is to simply parse it with packaging.version.Version, which will raise an exception if it's invalid.

But if you're currently relying on the interfaces supplied by setuptools/pkg_resources, the best way to determine if a version is valid may be something like this:

ver = pkg_resources.parse_version(input)
is_legacy = 'Legacy' in ver.__class__.__name__

That approach will work for old and future versions of pkg_resources for as long as I can foresee.

@jaraco jaraco closed this as completed Mar 18, 2018
tantale added a commit to laurent-laporte-pro/deprecated that referenced this issue Apr 2, 2018
…cyVersion`` are removed since setuptools >= 39. They are replaced by ``Version`` and ``LegacyVersion`` respectively. To check if the version is good, we now use the solution explained here: pypa/setuptools#1299.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants