[Python-Dev] Packaging and binary distributions for Python 3.3

[Vinay Sajip]

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

> 
> On 13 October 2011 17:25, Éric Araujo <merwok <at> netwok.org> wrote:
> >> My expectation would be that the user would type pysetup install
> >> some_binary_format_file.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 bdist_egg 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 bdist_simple 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 <unzip_location>.

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