With all of the current interest in bundling pip with the Python distribution, I had a sudden thought. Vinay has developed a package called pyzzer (https://pypi.python.org/pypi/pyzzer) that bundles up Python modules into runnable single-file executables. Using a command pyzzer -m pip:main -l t64 -o pipsa.exe -s "#!python" -r <path-to-pip>\pip you can build a single-file executable version of pip that can install wheels (it can't install sdists until setuptools is installed, because installing sdists depends on having setuptools at install time). The -s "#!python" is not needed on Unix as the default is "#!/usr/bin/env python". Also the -l t64 is a Windows requirement to get an exe - you can produce a cross-platform pyz archive without it (see the pyzzer docs for details). This requires the latest development version of pip (which contains a fix for running pip from an uninstalled zipfile) and the following patch to pip\__init__.py: Change: from pip import cmdoptions to: import pip.cmdoptions cmdoptions = pip.cmdoptions This fixes a recursive-import issue - I'll update pip "real soon now" (TM) for this. This is just an experiment at the moment - I've done minimal testing but it seems to work as I'd expect. It may be worth thinking about, though - either as an alternative to bundling (a bit late, I know) or as a way of providing pip for earlier versions of Python. Hope this is of interest. Paul
I did a bit of work looking at running pip from a .zip using pyzzer, a little while ago. What were the fixes to pip which you mentioned? There were a number of places where pip needed changing: 1. How it handles cacert.pem when running from a .zip (default_cert_path in pip/locations.py) 2. Identifying the running pip rather than any installed pip 3. Expecting an installed setuptools to check its version to confirm that wheels can be supported 4. The wheel build code, which uses subprocess, assumes running from the file system
From what I can see 2 and 3 have been addressed in recent changes, but I couldn't tell from a quick reading whether 1 has been addressed (there have certainly been code changes in this area) or whether 4 has been addressed.
Regards, Vinay Sajip -------------------------------------------- On Mon, 21/10/13, Paul Moore <p.f.moore@gmail.com> wrote: Subject: [Distutils] A portable version of pip To: "Distutils" <distutils-sig@python.org> Date: Monday, 21 October, 2013, 11:39 With all of the current interest in bundling pip with the Python distribution, I had a sudden thought. Vinay has developed a package called pyzzer (https://pypi.python.org/pypi/pyzzer) that bundles up Python modules into runnable single-file executables. Using a command pyzzer -m pip:main -l t64 -o pipsa.exe -s "#!python" -r <path-to-pip>\pip you can build a single-file executable version of pip that can install wheels (it can't install sdists until setuptools is installed, because installing sdists depends on having setuptools at install time). The -s "#!python" is not needed on Unix as the default is "#!/usr/bin/env python". Also the -l t64 is a Windows requirement to get an exe - you can produce a cross-platform pyz archive without it (see the pyzzer docs for details). This requires the latest development version of pip (which contains a fix for running pip from an uninstalled zipfile) and the following patch to pip\__init__.py: Change: from pip import cmdoptions to: import pip.cmdoptions cmdoptions = pip.cmdoptions This fixes a recursive-import issue - I'll update pip "real soon now" (TM) for this. This is just an experiment at the moment - I've done minimal testing but it seems to work as I'd expect. It may be worth thinking about, though - either as an alternative to bundling (a bit late, I know) or as a way of providing pip for earlier versions of Python. Hope this is of interest. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 21 October 2013 14:25, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
From what I can see 2 and 3 have been addressed in recent changes, but I couldn't tell from a quick reading whether 1 has been addressed (there have certainly been code changes in this area) or whether 4 has been addressed.
Yes, 3 in particular was the dev version change I mentioned. With regard to 1 and 4, I was only really considering installation from local wheels (the bootstrap case that ensurepip is aiming at) and neither of 1 and 4 affect that. In particular anything that builds from sdist needs a locally installed setuptools. It may be that "everything else" works if a local setuptools is installed, but I haven't tried. The cert issue is more annoying (insofar as installing wheels from PyPI *is* a reasonable thing to want to do) but the whole issue of certificate management (particularly from zip files) is messy. This may be a bug for requests to address, if they feel that running requests from a zipfile is a valid use case. Personally, I'd just say hang it and use pip's equivalent of "--no-check-certificate" (assuming there is one, I can't see it right now, but there'd better be!). There are certainly a lot of rough edges, and it may never be "production quality", but I was surprised at how usable it was. Paul PS In pyzzer, is there a reason that -s on Windows couldn't default to something (maybe just "#!python") that works for "the currently active Python" out of the box so it matches Unix? Maybe with a separate option to hard-code sys.executable for when you want to "freeze" the binary to the interpreter you're using for the build (which would be useful on Unix too)?
-------------------------------------------- On Mon, 21/10/13, Paul Moore <p.f.moore@gmail.com> wrote: PS In pyzzer, is there a reason that -s on Windows couldn't default to something (maybe just "#!python") that works for "the currently active Python" out of the box so it matches Unix? Maybe with a separate option to hard-code sys.executable for when you want to "freeze" the binary to the interpreter you're using for the build (which would be useful on Unix too)? The default is "#!/usr/bin/env python", which should search the path for a Python executable, including on Windows as long as the latest launcher version is installed.
On 21 October 2013 17:25, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
The default is "#!/usr/bin/env python", which should search the path for a Python executable, including on Windows as long as the latest launcher version is installed.
Not if you're using the exe launchers rather than a pyz file. The supplied launchers don't (as far as I can tell) include the /usr/bin/env logic from py.exe. I may be wrong, though, I'll do some more tests tomorrow. Paul
participants (2)
-
Paul Moore -
Vinay Sajip