My name is Phil Sayre. My email is sayrich1(a)gmail.com. I have written
a Python program which I will be using in my capacity as treasurer for a
small, 200 member group of chamber music aficionados. This program provides
an interactive interface to the person sitting in front of a laptop
computer, allowing him to look up a member's information, given the member's
name, and determine whether or not he has paid his dues for the current
year. It allows for corrections to the data, e.g., address, email, phone.
When the member pays $10, I will be able to mark him paid on the current
date with a mouse click. This program is easy to use and much faster and
simpler than using an Excel spreadsheet, which is the system I have had to
deal with for the past 2 years.
That is the justification for the program. Now I am wondering if I might
not be able to offer this program to other similar organizations, for
possibly a modest price. To do this I would have to know something about
packaging it as an installable product. I think the proper place to look
for answers is the Distutils sig, isn't it? But I confess at this
point, the documentation is just extremely confusing.
My program uses the CSV module to read and write 'comma separated
value' records from/to an Excel produced file, a package called EasyGui
which provides the user interface, and the modules shelve, sys, string,
cPickle, datetime. Shelve is the method which affords the fast record
lookup in the data base. The csv module is distributed with Python.
I am planning, for the time being, to offer this to only Windows users.
When I downloaded Python, I selected Pythonwin for my own laptop running
Windows XP. I don't really know much about this package other than it runs
For my probable customers, I don't expect that any of them will have a
Python system installed. And I don't need to provide them with a means of
editing and compiling Python programs--but I clearly will need to provide
the Python execution engine. But perhaps this is not separable from the
compiler--I don't know.
Where do fit within the Distutil spectrum? I think it's section 5, but I
can't get beyond the first paragraph.
I'd appreciate any help that is available.
New submission from Stefano Rivera <python-setuptools(a)rivera.za.net>:
It would be handy if specific 2to3 fixers could be disabled during 2to3. Here's a patch to do it. The equivalent patch for distutils2 would be much bigger, so I'm proposing it here for discussion, first.
title: Add option to suppress 2to3 fixes
Added file: http://bugs.python.org/setuptools/file70/skip-fixers.patch
Setuptools tracker <setuptools(a)bugs.python.org>
At 04:46 PM 9/3/2010 +0100, Nick Leaton wrote:
>I had an inkling I might be asking the wrong question.
>It relates to releasing an app that has the following features.
>1) Internal package
>2) A couple of scripts
>3) A dependency on an external package/library (Already packaged in
>its own right).
>4) A couple of dll or equivalent on Unix.
Note that dependencies can be automatically installed if you use
setuptools in your setup.py. The rest would also be part of a normal
>We don't want to install into site-packages, we want to keep that clean.
Why don't you leave that up to the person installing your
package? Is this for a small targeted audience or for general release?
If it's for general release to people using Python, you should most
definitely let them decide where to install it, or you're going to
make a lot of people really annoyed with you. ;-)
However, if it's to a targeted audience of non-Python users, why not
just have your installer pass appropriate installation locations to
setup.py install, to explicitly set things up the way you want them?
Either way, it doesn't seem like doing anything special in your
setup.py is a good idea. (Apart from maybe using setuptools so you
can specify dependencies.)
> We would like to install all the above into one directory
> structure, and set a python path to poin to the appropriate directory.
I ask these questions because there's more than one way to
(potentially) accomplish this, but so far it doesn't sound like
there's any reason for you to change the way distutils does things by
default, and leave it up to the person doing the installation to
decide where they want to put things, perhaps with some docs
recommending a particular location.
At 04:53 AM 9/1/2010 -0700, Jason R. Coombs wrote:
>We're using setuptools for packaging our Python projects. Several of our
>projects have a server/client aspect to them, where the server is a
>full-fledged service with a lot of dependencies and the client is just an API
>for accessing the server, probably with just a few dependencies. We want a
>way to install the package with or without these dependencies. With the
>current implementation of setuptools, I believe we have two choices.
>1) Refactor the package into three packages: project_server, project_client,
>and project_common. Project_server would then contain the additional
>2) Use the extras_require for the server facet of the project. So
>"easy_install project" installs the common dependencies and "easy_install
>project[server]" installs the additional dependencies.
>The second option is what we're using, but the [server] facet is the most
>common usage. We would prefer instead to have a way to "easy_install
>project[client]" which would _limit_ the dependencies needed, and
>"easy_install project" would install the full set of dependencies.
>Has anyone heard of a plugin which does this? Is it even possible that a
>plugin could trim out dependencies?
No, and no. A feature like this would have to be added to
setuptools, and even then, existing setuptools installations would
not know how to actually use the feature. In other words, even if
this were added, you would have the problem that, even many years
from now, there would still be users whose setuptools installation
wouldn't understand how to handle your special setup.
The most practical solution is to either go to option #1, or continue
to require explicitly specifying [client], [server] or [client,server]
At 10:03 AM 9/3/2010 +0100, Nick Leaton wrote:
>How can I get access to the value of --prefix from code during an install?
If you mean from setup.py, you can't. You would need to subclass one
of the distutils commands and ue the cmdclass argument to
setup(). (sys.prefix is the wrong answer, by the way; it contains
the prefix where python was installed, *not* the prefix being installed to!)
Even then, you don't want the value of --prefix, because that doesn't
necessarily tell you where something should be installed! Distutils
has multiple installation schemes, many of which don't use --prefix
at all. --prefix is used to calculate various paths, but those paths
can be specified individually, without using a --prefix.
What's more, when a --root installation is taking place, putting
things under --prefix would break bdist_rpm, bdist_wininst,
bdist_msi, and other bdist_* commands, which are actually installing
files to a temporary location in order to build an installation
package, rather than "really" installing anything.
In short, you're asking the wrong question, but if you can let us
know what it is you're planning to *do* with this information, there
may be an easier way to go about whatever you're actually trying to accomplish.
I'm quite fond of buildout, but a few things have taken me some months to
really figure out.
Buildout will remove any files installed by recipes when it senses that its
top parts or eggs section has changed.
I would love to avoid this as most of these removals are not needed, they
just get the same thing reinstalled afterwards,
lengthen the deploy time considerably and cause nasty surprises for the
server if its actually running.
Perhaps I'm not supposed to be using this for pushing changes to a live
server ? I'm using django and if anything changed
on the top parts/eggs then it gets reinstalled
(even from the download-cache this takes quite a while and causes bad
burps on the server by removing templates)
I see that there is a buildout::uninstall entry point for recipes to run
extra code, but no explicit uninstall method for the recipes.
Would it be possible to allow the recipe to implement uninstall if it
chooses to ? My django deploy could then be made to be lightening quick.
Maybe this project can be a reasonable starting point:
It works for the python 2.7x trunk but the same engine can be adapted to
different python versions with slight modifications.
Basically it will let you use different python version builds at the same-ish time,
side by side, so you can test your code vs different python revisions.
On Thu 02/09/10 12:39, "Godefroid Chapelle" gotcha(a)bubblenet.be wrote:
> Le 30/08/10 19:27, Jim Fulton a �crit :
> > On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers<chris@
> simplistix.co.uk> wrote:
>> Gary Poster wrote:
> >>>> It's not like I want my system
> matplotlib in one part and a locally
>>>> failing-horribly buildout-installed
> matplotlib in another part.
> >>> No, but single buildouts are used to install
> different sections with
>>> entirely different requirements, including
> different Python versions.
> >> This feels like needless complexity to
> > This is a requirement we had here at ZC. It
> >> If a different python is needed, it should be in
> its own buildout.
>> If you need to bundle a bunch of buildouts
> together because of this, use a
>> recipe that runs "sub buildouts" in a separate
> > It's possible that this would be a better approach.
> It's true that
> supporting multiple Python interpreters is a pain.
> I don't have this
> need atm, so I'm not motivated to try your solution.
> > I wonder what other people think. Does anyone else
> have current
> need to deal with multiple Python versions in the
> same buildout?
> > Jim
> I am developing vimpdb which I obviously want to be compatible with
> multiple python versions.
> I was planning to write a single buildout to build the various
> Godefroid Chapelle (aka __gotcha) http://bubblenet.be
> Distutils-SIG maillist - Distutils-SIG(a)python.org
We're using setuptools for packaging our Python projects. Several of our
projects have a server/client aspect to them, where the server is a
full-fledged service with a lot of dependencies and the client is just an API
for accessing the server, probably with just a few dependencies. We want a
way to install the package with or without these dependencies. With the
current implementation of setuptools, I believe we have two choices.
1) Refactor the package into three packages: project_server, project_client,
and project_common. Project_server would then contain the additional
2) Use the extras_require for the server facet of the project. So
"easy_install project" installs the common dependencies and "easy_install
project[server]" installs the additional dependencies.
The second option is what we're using, but the [server] facet is the most
common usage. We would prefer instead to have a way to "easy_install
project[client]" which would _limit_ the dependencies needed, and
"easy_install project" would install the full set of dependencies.
Has anyone heard of a plugin which does this? Is it even possible that a
plugin could trim out dependencies?
I can see how there are at least three approaches to this plugin:
1) Continue to define the additional requirements as extras, and then have
another parameter that selects the extras implicitly unless 'client' is
specified. I'm thinking of something like a "requires_extras_unless =
2) Have another parameter which re-lists those requirements which are not
required when project[client] is used.
3) Extend extras_require to allow keys such as '-client' or '!client', whose
values are only required if client is not specified.
I can forsee how any of these approaches could get messy and break lots of
assumptions about how extras and project dependencies are used. Any thoughts?