[Python-Dev] Packaging and binary distributions for Python 3.3 (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Sun Oct 16 23:32:34 CEST 2011

Paul Moore <p.f.moore gmail.com> writes:

On 13 October 2011 17:25, Éric Araujo <merwok netwok.org> wrote: >> My expectation would be that the user would type pysetup install >> somebinaryformatfile.zip and have that file unpacked and all the >> "bits" put in the appropriate place. Basically just like installing >> from a source archive - pysetup install project-1.0.tar.gz - but >> skipping the compile steps because the compiler output files are >> present. > Yep. > >> That may need some extra intelligence in pysetup if it doesn't have >> this feature already [...] just unzip the bits into the right place, >> or something similar. > Yes.  The bdist can be just like an sdist, but it contains compiled > files instead of C source files (maybe setuptools bdistegg is just > that), then pysetup uses the setup.cfg file to find files and install > them at the right places. I have uploaded an initial (working, just needs test, docs and some testing and possibly tidying up) version of bdistsimple in the tracker (http://bugs.python.org/issue13189).

There's one area of pysetup3 functionality which I don't think has been discussed in this thread, though it's pertinent to Windows users. Namely, a completely declarative approach to installation locations will not satisfy all requirements. For example, if you want to install PowerShell scripts, the right way of doing that is to make Shell API calls at installation time to determine the correct location for the installing user. I have this working at present for a project, using pysetup's hook functionality; but any move to a completely passive archive format would lose this kind of flexibility. So, I think whatever archive format we end up with should provide exactly the same level of flexibility we currently get with pysetup3 for pure-Python projects, but extended to include binary deliverables. The simplest way of doing this is to register those binaries in setup.cfg, and to have hook code check for the correct dependencies in the run-time environment before actually installing (e.g. x86/x64/ARM/Python version dependencies). While it's not the slickest solution imaginable, it does allow for just about all use cases. This flexibility is more important under Windows than under Posix, because the installation locations under Posix conform much more closely to a standard (FHS) than anything you find in the Windows environment.

Distribution build step = get all source, binary code and data defined in setup.cfg and in a single directory tree (containing the setup.cfg in the root of the tree), then zip that tree.

Distribution installation step = unzip aforementioned zip, and run pysetup3 install .

BTW, I believe that for virtual env installations, there's no need to provide integration with Add/Remove Programs. I find that the Add/Remove Programs dialog takes long enough to populate as it is :-(

Regards,

Vinay Sajip

More information about the Python-Dev mailing list