Re: [Distutils] Release: pip 6.0 and virtualenv 12.0
Why the jump from 1.5.6 to 6.0? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Release: pip 6.0 and virtualenv 12.0
On Tue, Dec 23, 2014 at 12:44 AM, Tshepang Lekhonkhobe tshep...@gmail.com wrote: Why the jump from 1.5.6 to 6.0? The release notes say (under 6.0): PROCESS Version numbers are now simply X.Y where the leading 1 has been dropped. (from https://pip.pypa.io/en/latest/news.html ) I'm guessing this is to start honoring the convention (e.g. from semver) that backwards incompatible changes should only be made when the major version number is incremented. --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
On Dec 23, 2014, at 1:23 AM, Marcus Smith qwc...@gmail.com wrote: In particular, , , ~=, and, when using a .*, the != and == use the number of dots in the given specifier to indicate the precision of the specifier. the PEP text is pretty clear on the precision concept for ~= and when using .*, but not so much for and . how about an example right there in that section that mentions the != V.* We can certainly clarify the PEP test to make it easier to understand. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 examples missing operator?
On Dec 23, 2014, at 1:03 AM, Marcus Smith qwc...@gmail.com wrote: oh, A compatible release clause consists of either a version identifier without any comparison operator or else the compatible release operator ~= On Mon, Dec 22, 2014 at 9:57 PM, Marcus Smith qwc...@gmail.com mailto:qwc...@gmail.com wrote: the first 3 examples here are confusing. https://www.python.org/dev/peps/pep-0440/#examples https://www.python.org/dev/peps/pep-0440/#examples there's no comparison operator? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig Heh, that’s actually a hold over from before we made specifiers mandatory. That needs updated. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 examples missing operator?
On 23 Dec 2014 19:02, Donald Stufft don...@stufft.io wrote: On Dec 23, 2014, at 1:03 AM, Marcus Smith qwc...@gmail.com wrote: oh, A compatible release clause consists of either a version identifier without any comparison operator or else the compatible release operator ~= On Mon, Dec 22, 2014 at 9:57 PM, Marcus Smith qwc...@gmail.com wrote: the first 3 examples here are confusing. https://www.python.org/dev/peps/pep-0440/#examples there's no comparison operator? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig Heh, that’s actually a hold over from before we made specifiers mandatory. That needs updated. Should we add a reference to the metadata issue tracker to the PEPs themselves? That's a better home for bug reports than the mailing list (Note I'm also happy to move the repo for metadata drafts to GitHub if folks would prefer that - it's a pretty simple repo, so git-hg bridges should handle the conversion easily. The issue migration would involve a bit more work, though). Cheers, Nick. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 examples missing operator?
Well you know my preferences is for github ;). I don't mind much either way though since its a simple repo I rarely need to interact with. The main benefit would be consistency with most of the other pypa things. I'm +1 on adding a bug tracker link. Maybe peps should support a header for it similar to discussions-to On Dec 23, 2014, at 6:42 AM, Nick Coghlan ncogh...@gmail.com wrote: On 23 Dec 2014 19:02, Donald Stufft don...@stufft.io wrote: On Dec 23, 2014, at 1:03 AM, Marcus Smith qwc...@gmail.com wrote: oh, A compatible release clause consists of either a version identifier without any comparison operator or else the compatible release operator ~= On Mon, Dec 22, 2014 at 9:57 PM, Marcus Smith qwc...@gmail.com wrote: the first 3 examples here are confusing. https://www.python.org/dev/peps/pep-0440/#examples there's no comparison operator? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig Heh, that’s actually a hold over from before we made specifiers mandatory. That needs updated. Should we add a reference to the metadata issue tracker to the PEPs themselves? That's a better home for bug reports than the mailing list (Note I'm also happy to move the repo for metadata drafts to GitHub if folks would prefer that - it's a pretty simple repo, so git-hg bridges should handle the conversion easily. The issue migration would involve a bit more work, though). Cheers, Nick. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Surviving a Compromise of PyPI - PEP 458 and 480
On Dec 22, 2014, at 1:15 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote: On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On 23 December 2014 at 01:46, Vladimir Diaz vladimir.v.d...@gmail.com mailto:vladimir.v.d...@gmail.com wrote: ::ping:: Has anyone in the community gotten a chance to review PEP 458 and/or PEP 480? Community feedback would be appreciated. Sorry about that Vladimir - I think the main PyPA devs have been focused on getting PEP 440 implemented, and the associated setuptools, pip and virtualenv updates out the door, and now we're into the end of year holiday period for many of us. Considering that the previous drafts of PEP 458 generated quite a bit of feedback and questions, I was surprised by the lack of responses this time around (almost relieved :). Receiving feedback from the main PyP developers after the holiday period is definitely not a problem. This is why I haven’t looked at it yet. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] New User: depends not appearing in control file
Hi!
I just started using stdeb but have run into a problem which I can't solve.
Just for background, so you know at what level to aim replies, I'm a long-time
programmer, over 30 years in fact. I make much of what I do available to
others but I've only just got around to packaging, so I know absolutely
nothing about how to package code (but I'm learning!).
I'm using stdeb 0.8.2 installed via pypi because the Ubuntu repos are so
hopelessly out of date.
I'm building a package for python3 only and uploading to an Ubuntu ppa which I
have done but with the following problems:
Here's my stdeb.cfg file:
[DEFAULT]
Depends: libav-tools (= 6:11), lsdvd (= 0.17), mplayer2 (= 2.0), python3-
pyqt4 (= 4.11), python3-pyudev (= 0.16)
XS-Python-Version: = 3.4
MIME-Desktop-Files: share/ravenc.desktop
Suite: utopic
Section: universe/video
Now here is the control file in the source package that is produced (minus the
package description, slightly redacted):
Source: ravenc
Maintainer: Geoff Clements e-mail address
Section: universe/video
Priority: optional
Build-Depends: python3-setuptools, python3-all, debhelper (= 7.4.3)
Standards-Version: 3.9.1
X-Python-Version: = 3.4
Package: python3-ravenc
Architecture: all
Depends: ${misc:Depends}, ${python3:Depends}
===
The problem here is that the dependencies have not been carried across to the
control file.
In addition, when I try to build a binary package I get this warning:
dpkg-gencontrol: warning: Depends field of package python3-ravenc: unknown
substitution variable ${python3:Depends}
This also appears in the build log if a submit the source packages to Ubuntu
to include in my ppa.
--
Geoff
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
Yes but thanks to Marc it now provides a clear message as to why. (Sent from my mobile) On Dec 23, 2014 11:22 AM, James Bennett ubernost...@gmail.com wrote: So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find anything installable? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote: it would fail. you'd need 1.7.0 On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com wrote: So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find anything installable? I think the thing I'd missed, which makes this behaviour more understandable (for me) is that you wouldn't usually get that in reality. Projects tend to use a fixed number of digits in the version number, so it'd likely be 1.7.0 and 1.7.1, and you'd be writing 1.7.0. Thinking of 1.7 as greater than the 1.7 series sort of helps me as well... Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Role of setuptools and eggs in modern distributing...
Hi folks, I'm trying to package up a complex system and would like to do it the correct, modern way. In particular, this involves a bunch of compiled extensions, as well as dependencies on both the scientific stack and common Web app packages. (can you tell I'm building a web service front-end for computational code?) This is actually a bit of a trick, because the web development community is generally doing a good job up supporting PyPi and pip, whereas the complications of the scientific software tools have folks relying more on tools like Enthought and Continuum. So far, we've been doing mostly pip and struggling with build our own for the ugly scientific stuff (whoo hoo, fun with HDF and netcdf, and GDAL, and). But at the end of all this we'd like to be able to distribute and make it easy on end users to use our tools. I figure we we'll do one (or both) of: - providing a custom wheel house with our packages and the dependencies that are hard to come by - provide a binstar channel with conda packages of all the same stuff but a totally different set of other packages. At the moment, I'm working on making conda packages, which brings me to my questions. I'm a bit confused about the role of setuptools with pip. On the one hand, pip depends of setuptools. On the other hand, pip supposed doesn't do eggs, and prefers wheels. But I find that I keep getting eggs whether I want them or not. IN fact, as far as I can tell, the way to get pip to instal something from git repo is: git+https://url_to_the_repo.git#egg=name_of_package why isn't that wheel=name_of_package and will it work if setuptools was not used in the packages setup.py??? Frankly I've generally found setuptools and eggs to be overly heavy weight and annoying -- the only reason I use setuptools at all is that I REALLY like develop mode -- which I can now get with pip --editable or does that give me setuptools develop mode anyway, i.e. do I need to have used setuptools.setup for it to work? So question one: do I need to use setuptools.setup rather than plain old distutils.setup? Question 2: What about setuptools: install_requires I generally like the pip requirements.txt approach. It's up to the installation tool, not the packaging tool to mange requirements. But then again, it does make sense to declare the requirements in setup.py. But the issue at hand is that install_requires is doing some odd things with conda: conda, of course, is designed to manage dependencies itself, and those are declared in the conda build meta.yaml file. Note that conda dependencies can have nothign to do with python -- the whole point of conda -- a conda pacakge can depend on any other conda package, including C libs, etc. But the issue at hand is that conda build doesn't re-invent setup.py -- but rather you generally simple call setup.py install from your conda build script. Hence th issue at hand: Using setuptools.setup, and specifying install_requires, then kicks in setuptools trying to resolve dependencies I don't want it to deal with. I read Donald's setup.py vs requirements.txt, and I guess I get it, but it still seems quite redundant -- I see the point of separating out “abstract dependencies” and “concrete dependencies”. However, the nifty solution of only putting: --index-url https://pypi.python.org/simple/ in the requirements.txt doesn't work for complex cases. In practice, we find we need to specify version numbers of some dependencies, and have some go strait into a git repo, etc. So we need a messy requirements.txt file. And, in fact, I think that's where is belongs -- the goal of the requirements.txt file is so pip can do the right thing and go grab everything you need. But, in fact, it also is quite human readable, and serves quite well as the documentation for the abstract dependencies as well. So I think the way to go is to keep requirements in requirements.txt, and leave them out of the setup.py. Can I dump setuptools.setup, as well?? Sorry, this is a bit rambling and short of clear questions, but I'm trying to get a handle on what best practices really are these days... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
It also provides consistency with date-based versions. And versions aren't decimals so thinking of them like that is not exactly useful. On Dec 23, 2014 11:43 AM, Paul Moore p.f.mo...@gmail.com wrote: On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote: it would fail. you'd need 1.7.0 On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com wrote: So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find anything installable? I think the thing I'd missed, which makes this behaviour more understandable (for me) is that you wouldn't usually get that in reality. Projects tend to use a fixed number of digits in the version number, so it'd likely be 1.7.0 and 1.7.1, and you'd be writing 1.7.0. Thinking of 1.7 as greater than the 1.7 series sort of helps me as well... Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Role of setuptools and eggs in modern distributing...
On Dec 23, 2014, at 12:36 PM, Chris Barker chris.bar...@noaa.gov wrote: Hi folks, I'm trying to package up a complex system and would like to do it the correct, modern way. In particular, this involves a bunch of compiled extensions, as well as dependencies on both the scientific stack and common Web app packages. (can you tell I'm building a web service front-end for computational code?) This is actually a bit of a trick, because the web development community is generally doing a good job up supporting PyPi and pip, whereas the complications of the scientific software tools have folks relying more on tools like Enthought and Continuum. So far, we've been doing mostly pip and struggling with build our own for the ugly scientific stuff (whoo hoo, fun with HDF and netcdf, and GDAL, and). But at the end of all this we'd like to be able to distribute and make it easy on end users to use our tools. I figure we we'll do one (or both) of: - providing a custom wheel house with our packages and the dependencies that are hard to come by - provide a binstar channel with conda packages of all the same stuff but a totally different set of other packages. At the moment, I'm working on making conda packages, which brings me to my questions. I'm a bit confused about the role of setuptools with pip. On the one hand, pip depends of setuptools. On the other hand, pip supposed doesn't do eggs, and prefers wheels. But I find that I keep getting eggs whether I want them or not. IN fact, as far as I can tell, the way to get pip to instal something from git repo is: git+https://url_to_the_repo.git#egg=name_of_package https://url_to_the_repo.git/#egg=name_of_package why isn't that wheel=name_of_package and will it work if setuptools was not used in the packages setup.py??? Frankly I've generally found setuptools and eggs to be overly heavy weight and annoying -- the only reason I use setuptools at all is that I REALLY like develop mode -- which I can now get with pip --editable or does that give me setuptools develop mode anyway, i.e. do I need to have used setuptools.setup for it to work? So question one: do I need to use setuptools.setup rather than plain old distutils.setup? Question 2: What about setuptools: install_requires I generally like the pip requirements.txt approach. It's up to the installation tool, not the packaging tool to mange requirements. But then again, it does make sense to declare the requirements in setup.py. But the issue at hand is that install_requires is doing some odd things with conda: conda, of course, is designed to manage dependencies itself, and those are declared in the conda build meta.yaml file. Note that conda dependencies can have nothign to do with python -- the whole point of conda -- a conda pacakge can depend on any other conda package, including C libs, etc. But the issue at hand is that conda build doesn't re-invent setup.py -- but rather you generally simple call setup.py install from your conda build script. Hence th issue at hand: Using setuptools.setup, and specifying install_requires, then kicks in setuptools trying to resolve dependencies I don't want it to deal with. I read Donald's setup.py vs requirements.txt, and I guess I get it, but it still seems quite redundant -- I see the point of separating out “abstract dependencies” and “concrete dependencies”. However, the nifty solution of only putting: --index-url https://pypi.python.org/simple/ https://pypi.python.org/simple/ in the requirements.txt doesn't work for complex cases. In practice, we find we need to specify version numbers of some dependencies, and have some go strait into a git repo, etc. So we need a messy requirements.txt file. And, in fact, I think that's where is belongs -- the goal of the requirements.txt file is so pip can do the right thing and go grab everything you need. But, in fact, it also is quite human readable, and serves quite well as the documentation for the abstract dependencies as well. So I think the way to go is to keep requirements in requirements.txt, and leave them out of the setup.py. Can I dump setuptools.setup, as well?? Sorry, this is a bit rambling and short of clear questions, but I'm trying to get a handle on what best practices really are these days... -Chris I’m going to attempt to read between the lines here a little bit. The “egg” name is heavily overloaded in setuptools. It is used all over the place for varying sets of related but distinct concepts. The #egg= thing is one of those setuptools concepts where it used that name for something distinct but similar. Ideally it shouldn’t be #egg= or #wheel= but should be #dist= or something similar since it’s neither an egg or a Wheel and there is an open ticket in pip’s issue tracker to do that. To make a clarification though, pip itself doesn’t depend
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
On 23 Dec 2014, at 18:43, Paul Moore p.f.mo...@gmail.com wrote: On 22 December 2014 at 20:44, Marcus Smith qwc...@gmail.com wrote: it would fail. you'd need 1.7.0 On Mon, Dec 22, 2014 at 12:36 PM, James Bennett ubernost...@gmail.com wrote: So, if PyPI has foo-1.7 and foo-1.7.1, does 1.7 just fail to find anything installable? I think the thing I'd missed, which makes this behaviour more understandable (for me) is that you wouldn't usually get that in reality. Projects tend to use a fixed number of digits in the version number, so it'd likely be 1.7.0 and 1.7.1, and you'd be writing 1.7.0. For what it’s worth I usually skip a trailing .0 in my versions since it does not add any extra information. So my packages tend to do 1.6 1.6.1 1.6.2 1.7 1.7.1 etc. etc. Wichert. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Role of setuptools and eggs in modern distributing...
git+https://url_to_the_repo.git#egg=name_of_package why isn't that wheel=name_of_package the egg part here has nothing to do with eggs. just a vestige of another time. see https://github.com/pypa/pip/issues/1265 and will it work if setuptools was not used in the packages setup.py??? yes, it would work. which I can now get with pip --editable or does that give me setuptools develop mode anyway -e uses setuptools develop mode. So question one: do I need to use setuptools.setup rather than plain old distutils.setup? the main reason for setuptools is for install_requires, which is fundamental to pip dependency resolution. but in general, it offers more features and it's more maintained than pure distutils. The standard advice is to use setuptools over distutils. I generally like the pip requirements.txt approach. It's up to the installation tool, not the packaging tool to mange requirements. But then again, it does make sense to declare the requirements in setup.py. But the issue at hand is that install_requires is doing some odd things with conda: The Packaging User Guide has a breakdown of install_requires vs requirements files. https://packaging.python.org/en/latest/technical.html#install-requires-vs-requirements-files In brief, requirements files are usually for a whole environment, whereas install_requires is for a project. install_requires is critical when publishing projects to PyPI. Even if you're not publishing, install_requires is helpful to safely attempt an upgrade of your dependencies. Instead of installing your app from a frozen requirements file, you would install normally in a clean environment (based on install_requires) and let any upgrades occur, and then you can re-freeze your requirements. But if you are doing mostly vcs installs in your requirements file, then it's true that maintaining install_requires can be somewhat pointless, although I would still say it's helpful to keep track of each project's first level abstract dependencies are, even if the install_requires declarations aren't being used. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440: foo-X.Y.Z does not satisfy fooX.Y?
just post edit suggestions here? https://bitbucket.org/pypa/pypi-metadata-formats is not up to date anymore some other location? On Tue, Dec 23, 2014 at 1:01 AM, Donald Stufft don...@stufft.io wrote: On Dec 23, 2014, at 1:23 AM, Marcus Smith qwc...@gmail.com wrote: In particular, , , ~=, and, when using a .*, the != and == use the number of dots in the given specifier to indicate the precision of the specifier. the PEP text is pretty clear on the precision concept for ~= and when using .*, but not so much for and . how about an example right there in that section that mentions the != V.* We can certainly clarify the PEP test to make it easier to understand. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP440 examples missing operator?
Heh, that’s actually a hold over from before we made specifiers mandatory. That needs updated. you mean made operators mandatory? so the bit about version identifier without any comparison operator needs to be removed? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
