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

[Éric Araujo]

Le 09/10/2011 22:14, Paul Moore a écrit :
> On 9 October 2011 20:47, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> PEP 376 provide the installation format for the 'future' --
>> http://www.python.org/dev/peps/pep-0376/
> [...]
>> Now for a binary archive, that would get installed ala PEP 376, why
>> not ? I'd just be curious to have someone list the advantage of having
>> a project released that way besides the "importable as-is" feature.
I think I don’t understand you here.  IMO, bdists are just intermediary
formats that are supposed to be consumed by installation tools.  Users
are not expected to import from bdists.

> 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.

Alternatively, the bdist format could put build files into a few
top-level directories, using sysconfig names: config,
appdata, doc, purelib, platlib, etc.  pysetup would then move files to
the right target directory.

> As regards the format, bdist_dumb is about the right level - but
> having just checked it has some problems (which if I recall, have been
> known for some time, and are why bdist_dumb doesn't get used).
Or maybe because it’s just useless: Windows users want to click many
times, Mac OS users want to drag-and-drop things, free OS users are fine
with sdists.

> Specifically, bdist_dumb puts the location of site-packages ON THE
> BUILD SYSTEM into the archive, making it useless for direct unzipping
> on a target system which has Python installed somewhere else.
pysetup would not just unzip it though, so maybe this limitation is not
really one.

> a new name might be needed if backward compatibility of the old
> broken format matters...
The point of forking distutils under a new name is that we can break compat.

> I don't know the code at all, and I have little time
Your time is best used with giving user expectations and feedback.  I
hope to get a Windows VM soon-ish, so I should not even pester people
for testing my patches :)

> PS The problem for me is that if pysetup only handles source builds,
> it's STILL annoyingly incomplete for my requirements (and possibly
> many Windows users')
Agreed.  packaging does not want to exclude Windows users.

[Nick]
> bdist_zip, bdist_archive, bdist_simple would all work (bdist_binary is
> redundant, given what the 'b' stands for).
Isn’t calling zipfiles “archives” an abuse?  I like bdist_simple.

On a related topic, I’m not sure the bdist comand is useful.  Its only
role is to translate “bdist --formats zip,targz,wininst” to calls to the
other bdist_* commands.

> The 'bdist_dumb' name has always irritated me, since the connotations
> more strongly favour 'stupid' than they do 'simple'
I’ve also recently learned that people with mental illness can be hurt
by derogatory uses of “dumb”, so if we change the name to reflect the
change in behavior, it’d have the nice side-effect of being nicer.

[Vinay]
> A simple change to packaging will allow an archive containing a setup.cfg-based
> directory to be installed in the same way as a source directory.
Isn’t that already supported, as long as the tarball or zipfile contains
source files?  In any case, it was intended to be, and there’s still
support code around.

> the current installer stub (wininst-x.y.exe) does not know anything
> about virtual environments. If we care about virtual environment support (and I
> think we should), wininst.exe could be enhanced to provide a "Browse..." button
> to allow a user to select a virtual environment to install into,
Personally, I’ll focus on sdist and bdist_simple support.  When pysetup
is run from a virtualenv, projects will be installed into the venv.  You
are free to work on patches for bdist_wininsts, but I’m not sure it will
be needed, if we make the pysetup user experience smooth enough.  That
said, even if Paul was convinced to forsake clicky installers, maybe
some Windows users will absolutely refuse to use the command line.

[Paul]
> To summarise, then:
> 
> 1. By using setup.cfg technology, it would be easy enough to zip up a
> binary build in a way that pysetup could unpack and install.
Correct.  I’m still pondering whether I find the idea of registering
built files in setup.cfg as elegant or hacky :)  We also have the other
ideas I wrote to choose from.

>    1a. A packaging command to build such an archive would be worth providing.
Definitely.  Maybe we could also decide on one of wininst or msi?

> 2. A GUI installer would still be valuable for many people
>    2a. Having the GUI work by doing a pysetup install passing the
> installer exe (which would have a zipfile as noted in 1 above
> appended) could make sense to avoid duplicating work.
Yes.

>    2b. The GUI could do the extra needed to integrate with the OS,
> which pysetup wouldn't do
Nice property.

>    2c. There's a question over a GUI install followed by a pysetup
> uninstall, which wouldn't remove the add/remove entry...
I think we could require that a project installed with a clicky
wininst_bdist has to be removed via the Add/Remove GUI.  (There is
support for that in PEP 376: the INSTALLER file.)

> 3. Ideally, the GUI should co-operate with venvs, by offering some
> form of browse facility. The command line does this automatically.
Will Windows users want a GUI to create venvs too?

[Vinay]
> I looked at the dialog resources for wininst-x.y.exe and noticed that there is a
> "Find other ..." button which is hidden, and its handler (in
> PC\bdist_wininst\install.c) is commented out. However, the code called by the
> handler - GetOtherPythonVersion - is still there. Does anyone here know why the
> button has been made unavailable?
hg blame tells that this has been commented out since the initial commit
to Subversion.  Maybe the previous CVS history will yield more info.

Regards