-
Notifications
You must be signed in to change notification settings - Fork 90
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
Use of pkg_resources for package versions #41
Comments
I've looked at #15, but I don't understand the issue. Surely the package names and numbers reported via pip are the ones that you want to report, rather than the value of some internal attribute. |
Honestly has been so long that I don't remember why I chose one over the other, but I think I think it's useful to support these Python versions for people who deliberately have to use an old python version on a webserver or so. On the other hand, this is a IPython magic command, so there may not be an intersection of people who have IPython installed but yet have such an old setuptools version. So I agree with you changing to |
I'm happy to make these changes when I have time, but it will be a major version since it changes the meaning of the -p flag (from modules to packages). It is worth dropping guaranteed support for Python 2 at the same time? i.e. for version 2.0. IPython hasn't supported it 2 major versions ago. https://python3statement.org/. In fact, IPython 7.0+ only supports Python 3.5 and above. |
That's a tough question. Making features like this easier to implement is exactly the reason why I think people should "slowly" start about dropping Py 2 support if they haven't done so already. However, So, I am afraid dropping Py2 makes this less useful, because people who are voluntarily or involuntarily using Python 2.7 but then unable to install watermark for a reason unknown to them (thinking of beginners), and then it will just be another hurdle to them to find out why they can't install it etc.. Anyways, usually, I am in favor of dropping Py 2 support, but maybe we shouldn't do that just yet. I do think though a (deprecation) warning should be displayed if a person runs watermark in IPython on Python 2.7 as a start. |
If the change was made in v2.0 then v1.x would still install on Python 2.7 just as IPython 5.x does |
That sounds good to me then. Have never done that before -- you are basically saying we can specify the IPython/Python dependency of the 2.0 version somewhere in the setup.py file so that people on Python 2.7 get the correct (compatible) 1.7 version when they run |
Started work on this here: https://github.com/jamesmyatt/watermark/tree/v2-pre I also noticed that some of the methods already use the Python 3 print function without importing from future: watermark/watermark/watermark.py Line 236 in 3f2c75a
|
Good point. That's a contributed function, personally, I don't use |
I think that str.format was backported from Python 3.0 to Python 2.6 |
Should be addressed now via #54 (using pkg_resources) |
Thanks for doing this 👍 |
Is there a reason why
_get_packages
doesn't usepkg_resources
to get the package version numbers, likepip
does?The version attributes inside the imported modules are not guaranteed to exist or to match the version that pip (or conda) understand. pkg_resources is the way to do this. Otherwise you risk one or more of the following recommended approaches not working: https://packaging.python.org/guides/single-sourcing-package-version/.
The text was updated successfully, but these errors were encountered: