<div class="gmail_quote">On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
End users should not need packaging tools on their machines.<br></blockquote><div><br>Well, unless they're developers. ;-) Sometimes, the "end user" is a developer making use of a library.<br> <br><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Development tools like distutils2, distribute/setuptools, bento would<br>
*only* be needed on developer machines, and would be purely developer<br>
choice. They would all interact with end users via the<br>
stdlib-supported standard formats. They could live outside the stdlib,<br>
and developers could use whichever tool suited them.<br></blockquote><div><br>AFAIK, this was the goal behind setup.cfg in packaging, and it's a goal I agree with.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is a radical idea in that it does not cater for the "zipped up<br>
development directory as a distribution format" mental model that<br>
current Python uses. That model could still work, but only if all the<br>
tools generated a stdlib-supported build definition </blockquote><div><br>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.<br>
<br>(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.)<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
PS I know that setuptools includes some end-user aspects -<br>
multi-versioning, entry points and optional dependencies, for example.<br>
Maybe these are needed - personally, I have never had a need for any<br>
of these, so I'm not the best person to comment.<br></blockquote><div><br>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.<br>
<br>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:<br><br> <a href="http://pypi.python.org/pypi/celery-with-couchdb">http://pypi.python.org/pypi/celery-with-couchdb</a><br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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. ;-) ) <br>
</div></div><br>