On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> End users should not need packaging tools on their machines.
>
Well, unless they're developers. ;-) Sometimes, the "end user" is a
developer making use of a library.
Development tools like distutils2, distribute/setuptools, bento would
> *only* be needed on developer machines, and would be purely developer
> choice. They would all interact with end users via the
> stdlib-supported standard formats. They could live outside the stdlib,
> and developers could use whichever tool suited them.
>
AFAIK, this was the goal behind setup.cfg in packaging, and it's a goal I
agree with.
> This is a radical idea in that it does not cater for the "zipped up
> development directory as a distribution format" mental model that
> current Python uses. That model could still work, but only if all the
> tools generated a stdlib-supported build definition
Again, packaging's setup.cfg is, or should be, this. I think there are
some technical challenges with the current state of setup.cfg, but AFAIK
they aren't anything insurmountable.
(Background: the general idea is that setup.cfg contains "hooks", which
name Python callables to be invoked at various stages of the process.
These hooks can dynamically add to the setup.cfg data, e.g. to list
newly-built files, binaries, etc., as well as to do any actual building.)
PS I know that setuptools includes some end-user aspects -
> multi-versioning, entry points and optional dependencies, for example.
> Maybe these are needed - personally, I have never had a need for any
> of these, so I'm not the best person to comment.
>
Entry points are a developer tool, and cross-project co-ordination
facility. They allow packages to advertise classes, modules, functions,
etc. that other projects may wish to import and use in a programmatic way.
For example, a web framework may say, "if you want to provide a page
template file format, register an entry point under this naming convention,
and we will automatically use it when a template has a matching file
extension." So entry points are not really consumed by end users;
libraries and frameworks use them as ways to dynamically co-ordinate with
other installed libraries, plugins, etc.
Optional dependencies ("extras"), OTOH, are for end-user convenience: they
allow an author to suggest configurations that might be of interest.
Without them, people have to do things like this:
http://pypi.python.org/pypi/celery-with-couchdb
in order to advertise what else should be installed. If Celery were
instead to list its couchdb and SQLAlchemy requirements as "extras" in
setup.py, then one could "easy_install celery[couchdb]" or "easy_install
celery[sqla]" instead of needing to register separate project names on PyPI
for each of these scenarios.
As it happens, however, two of the most popular setuptools add-ons (pip and
buildout) either did not or still do not support "extras", because they
were not frequently used. Unfortunately, this meant that projects had to
do things like setup dummy projects on PyPI, because the popular tools
didn't support the scenario.
In short, nobody's likely to mourn the passing of extras to any great
degree. They're a nice idea, but hard to bootstrap into use due to the
chicken-and-egg problem. If you don't know what they're for, you won't use
them, and without common naming conventions (like mypackage[c_speedups] or
mypackage[test_support]), nobody will get used to asking for them. I think
at some point we will end up reinventing them, but essentially the
challenge is that they are a generalized solution to a variety of small
problems that are not individually very motivating to anybody. They were
only motivating to me in the aggregate because I saw lots of individual
people being bothered by their particular variation on the theme of
auxiliary dependencies or recommended options.
As for multi-versioning, it's pretty clearly a dead duck, a
proof-of-concept that was very quickly obsoleted by buildout and
virtualenv. Buildout is a better implementation of multi-versioning for
actual scripts, and virtualenvs work fine for people who haven't yet
discovered the joys of buildout. (I'm a recent buildout convert, in case
you can't tell. ;-) )
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
