Re: [Distutils] pip does not work as expected from a zip
On Thu, Sep 12, 2013 at 1:51 PM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > >> In wheel's case the idea was to have pip verify that the optional >> dependency is new enough to work. The part inside pip could be changed >> to try: import wheel; check(wheel.__version__). IIRC the pip process >> itself does not directly use anything inside wheel and does not need >> to "import wheel". > > I see what you're saying, but I was commenting about checks for setuptools > and pip. There's no analogous check for wheel, since as you say, pip doesn't > use wheel directly. > >> However "setup.py bdist_wheel ...", run by pip in a subprocess, will >> not work unless setuptools can find wheel's plugin declaration. That >> won't work unless wheel's *.dist-info/entry_points.txt on sys.path. > > Yes, I see. Perhaps it's a shame it was implemented that way, if it means > it's harder or not possible to run pip from a .zip :-( I'm suggesting it might be a bug in pkg_resources, or it might be something pkg_resources can already do, if pip.zip is added to PYTHONPATH while executing setup.py in a subprocess. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Packaging panel in Montreal next year?
I could make it this time. I was considering submitting a talk about a library I have been working on recently for dependency solving. Would that fall into what you had in mind ? It is designed to be fairly agnostic toward metadata format, installation scheme, etc... It handles arbitrary dependency, the concept of replaces/obsolete, and provides. The current code live at https://github.com/enthought/depsolver I haven't announced yet because it still needs some improvements, but a similar design has been proved to work fairly well for php (composer), OpenSuse (libzypp) and considered for Fedora ( https://fedoraproject.org/wiki/Features/DNF). David On Thu, Sep 12, 2013 at 5:39 PM, Nick Coghlan wrote: > The PyCon submission deadline is just a few days away, and I'm planning to > submit a packaging Q&A panel again (same concept as the one this year, but > with a further 12 months of progress to report). > > Before I do that, though, I just wanted to check there would be at least a > few other distutils-sig denizens around that I could dragoon into > participating. > > While it seems like a pretty safe bet, I don't see any reason to rely on > assumptions when I don't need to :) > > Cheers, > Nick. > > ___ > 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] pip does not work as expected from a zip
Paul Moore gmail.com> writes: > I'd say yes, raise an issue on the pip tracker. At a minimum, it will > ensure that the issue is discussed and the conclusion recorded. Okay, will do. > Personally, I'd say that zipping up pip should work. Whether it's > valid to require people to include dist-info directories in zips, as > Daniel says, I'm not sure - maybe it should be a requirement, but if > so, then the python docs on how to zip up files to make executable > zips should document this (potential) requirement. I don't believe it should be a requirement - wherever possible, Python code shouldn't need to be installed into a site-packages in order to work. > Without seeing the surrounding code, I can't say whether the use of > pkg_resources here is valid. Since in each case here it's just checking versions, I would say that it's not really necessary. These are the only two cases in pip where it's searching using string literals 'setuptools' and 'pip' - as these are actually a dependency and pip itself, it shouldn't really need to look for an installed distribution, since the fact that it's running means that (under normal circumstances) it's using imported code rather than installed code (which is what leads to the errors, of course). Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip does not work as expected from a zip
On Thu, Sep 12, 2013 at 12:24 PM, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > >> I'd say yes, raise an issue on the pip tracker. At a minimum, it will >> ensure that the issue is discussed and the conclusion recorded. > > Okay, will do. > >> Personally, I'd say that zipping up pip should work. Whether it's >> valid to require people to include dist-info directories in zips, as >> Daniel says, I'm not sure - maybe it should be a requirement, but if >> so, then the python docs on how to zip up files to make executable >> zips should document this (potential) requirement. > > I don't believe it should be a requirement - wherever possible, Python code > shouldn't need to be installed into a site-packages in order to work. > >> Without seeing the surrounding code, I can't say whether the use of >> pkg_resources here is valid. > > Since in each case here it's just checking versions, I would say that it's > not really necessary. These are the only two cases in pip where it's > searching using string literals 'setuptools' and 'pip' - as these are > actually a dependency and pip itself, it shouldn't really need to look for > an installed distribution, since the fact that it's running means that > (under normal circumstances) it's using imported code rather than installed > code (which is what leads to the errors, of course). > > Regards, > > Vinay Sajip In wheel's case the idea was to have pip verify that the optional dependency is new enough to work. The part inside pip could be changed to try: import wheel; check(wheel.__version__). IIRC the pip process itself does not directly use anything inside wheel and does not need to "import wheel". However "setup.py bdist_wheel ...", run by pip in a subprocess, will not work unless setuptools can find wheel's plugin declaration. That won't work unless wheel's *.dist-info/entry_points.txt on sys.path. It is true that pip has a greater dependency on "knowing what's installed" than most Python software and therefore needs the -info directories that provide the installation database. Programs that are not installers and do not use entry_points usually do fine with just "try: import x". ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip does not work as expected from a zip
Daniel Holth gmail.com> writes: > In wheel's case the idea was to have pip verify that the optional > dependency is new enough to work. The part inside pip could be changed > to try: import wheel; check(wheel.__version__). IIRC the pip process > itself does not directly use anything inside wheel and does not need > to "import wheel". I see what you're saying, but I was commenting about checks for setuptools and pip. There's no analogous check for wheel, since as you say, pip doesn't use wheel directly. > However "setup.py bdist_wheel ...", run by pip in a subprocess, will > not work unless setuptools can find wheel's plugin declaration. That > won't work unless wheel's *.dist-info/entry_points.txt on sys.path. Yes, I see. Perhaps it's a shame it was implemented that way, if it means it's harder or not possible to run pip from a .zip :-( Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP449 - Removal of the PyPI Mirror Auto Discovery and Naming Scheme
On 12 Sep 2013 17:24, "Christian Theune" wrote: > > Hi, > > On 27. Aug2013, at 5:22 PM, Christian Theune wrote: > > > > I'll be a bit more aggressive with the migration and plan to do the following things: > > […] > > In two weeks: > > > > - Make f.pypi.python.org serve 401 Gone > > This is done now. f.pypi.python.org does not serve any meaningful content any longer. > > I'd suggest keeping the DNS around for a few more weeks so people get to see the 410 and fix their setups. Thanks for working through this Christian! Cheers, Nick. > > Christian > > -- > Christian Theune · gocept gmbh & co. kg > flyingcircus.io · operations as a service > Forsterstraße 29 · 06112 Halle (Saale) · Tel +49 345 1229889-7 > ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Packaging panel in Montreal next year?
The PyCon submission deadline is just a few days away, and I'm planning to submit a packaging Q&A panel again (same concept as the one this year, but with a further 12 months of progress to report). Before I do that, though, I just wanted to check there would be at least a few other distutils-sig denizens around that I could dragoon into participating. While it seems like a pretty safe bet, I don't see any reason to rely on assumptions when I don't need to :) Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip does not work as expected from a zip
On Thu, Sep 12, 2013 at 2:14 PM, Daniel Holth wrote: > I'm suggesting it might be a bug in pkg_resources, or it might be > something pkg_resources can already do, if pip.zip is added to > PYTHONPATH while executing setup.py in a subprocess. pkg_resources can detect subdirectories in a zip that are named "whatever-version.egg/", and treat them like egg files or directories. I don't recall whether it can detect .egg-info in .zip, though; I don't think I specifically implemented that, so if it works, it's by virtue of a good orthogonal design rather than any specific intent for it to work. ;-) My guess, though, is that the "basket" support (i.e. zipped .egg subdirectories) is the only way at the moment to bundle multiple distributions in a .pyz or other archive. (Note: I don't mean putting an .egg file in the .zip, just zipping up an .egg directory and including it as a subdirectory inside the main .zip/.pyz/whatever.) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip does not work as expected from a zip
Daniel Holth gmail.com> writes: > It ought to be able to find the .dist-info or .egg-info directories > inside the .pyz? Perhaps, but as I didn't actually install those distributions, no .dist-info or .egg-info were available, and so not present in the .pyz. If we want better uptake of .zip-bundled applications as per PEP 441, ISTM we shouldn't *require* such directories to be placed inside .zip files. Does pyzaa create such directories inside .zip files it makes? Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip does not work as expected from a zip
It ought to be able to find the .dist-info or .egg-info directories
inside the .pyz?
On Thu, Sep 12, 2013 at 10:38 AM, Vinay Sajip wrote:
> When run from a .zip file, pip does not seem to work as expected - it seems
> to need to be conventionally installed.
>
> I zipped up pip 1.4.1, setuptools (1.1.4) and wheel (0.21.0) into a .pyz. I
> have pip 1.0 and setuptools 0.6 installed in system site-packages.
>
> If I run "pip.pyz --version", it prints "1.0" rather than "1.4.1". If I run
> "pip.pyz wheel", it tells me that it needs setuptools >= 0.8.
>
> The problem seems to be that in at least these two places, pip runs code
> looking like
>
> dist = pkg_resources.get_distribution('XXX')
>
> which of course will not find the setuptools or pip in the .pyz.
>
> Is this behaviour by design? If so, it seems somewhat sub-optimal. If not,
> should I create an issue on the pip tracker?
>
> Regards,
>
> Vinay Sajip
>
> ___
> 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] pip does not work as expected from a zip
On 12 September 2013 15:38, Vinay Sajip wrote:
> The problem seems to be that in at least these two places, pip runs code
> looking like
>
> dist = pkg_resources.get_distribution('XXX')
>
> which of course will not find the setuptools or pip in the .pyz.
>
> Is this behaviour by design? If so, it seems somewhat sub-optimal. If not,
> should I create an issue on the pip tracker?
I'd say yes, raise an issue on the pip tracker. At a minimum, it will
ensure that the issue is discussed and the conclusion recorded.
Personally, I'd say that zipping up pip should work. Whether it's
valid to require people to include dist-info directories in zips, as
Daniel says, I'm not sure - maybe it should be a requirement, but if
so, then the python docs on how to zip up files to make executable
zips should document this (potential) requirement.
Without seeing the surrounding code, I can't say whether the use of
pkg_resources here is valid.
Paul
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] pip does not work as expected from a zip
When run from a .zip file, pip does not seem to work as expected - it seems
to need to be conventionally installed.
I zipped up pip 1.4.1, setuptools (1.1.4) and wheel (0.21.0) into a .pyz. I
have pip 1.0 and setuptools 0.6 installed in system site-packages.
If I run "pip.pyz --version", it prints "1.0" rather than "1.4.1". If I run
"pip.pyz wheel", it tells me that it needs setuptools >= 0.8.
The problem seems to be that in at least these two places, pip runs code
looking like
dist = pkg_resources.get_distribution('XXX')
which of course will not find the setuptools or pip in the .pyz.
Is this behaviour by design? If so, it seems somewhat sub-optimal. If not,
should I create an issue on the pip tracker?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP449 - Removal of the PyPI Mirror Auto Discovery and Naming Scheme
Hi, On 27. Aug2013, at 5:22 PM, Christian Theune wrote: > > I'll be a bit more aggressive with the migration and plan to do the following > things: > […] > In two weeks: > > - Make f.pypi.python.org serve 401 Gone This is done now. f.pypi.python.org does not serve any meaningful content any longer. I'd suggest keeping the DNS around for a few more weeks so people get to see the 410 and fix their setups. Christian -- Christian Theune · gocept gmbh & co. kg flyingcircus.io · operations as a service Forsterstraße 29 · 06112 Halle (Saale) · Tel +49 345 1229889-7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
