Mailman 3 September 2010 - Distutils-SIG

Need for some guidance
by Phil Sayre & Jean Richon 06 Sep '10

06 Sep '10

Hello, 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 under Windows. 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.

3 2

[issue114] Add option to suppress 2to3 fixes
by Stefano Rivera 05 Sep '10

05 Sep '10

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. ---------- files: skip-fixers.patch messages: 541 nosy: stefanor priority: feature status: unread 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> <http://bugs.python.org/setuptools/issue114> _______________________________________________

1 0

Re: [Distutils] --prefix
by P.J. Eby 03 Sep '10

03 Sep '10

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 setup script. >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. Why? 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.

1 0

Re: [Distutils] Need for ability to limit dependencies similar to 'extras'
by P.J. Eby 03 Sep '10

03 Sep '10

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

1 0

Re: [Distutils] --prefix
by P.J. Eby 03 Sep '10

03 Sep '10

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.

2 1

--prefix
by Nick Leaton 03 Sep '10

03 Sep '10

How can I get access to the value of --prefix from code during an install? Thanks -- Nick

3 2

buildout removes parts on any change
by felix 02 Sep '10

02 Sep '10

hello, 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. -felix

2 4

Re: [Distutils] different python versions in one buildout?!
by a.cavallo＠cavallinux.eu 02 Sep '10

02 Sep '10

Maybe this project can be a reasonable starting point: http://pyvm.sf.net 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. Regards Antonio 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 > me. > > > This is a requirement we had here at ZC. It > wasn't > needless. > > > >> 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 > process... > > > 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 > testrunners. > -- > Godefroid Chapelle (aka __gotcha) http://bubblenet.be > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig > >

1 0

Need for ability to limit dependencies similar to 'extras'
by Jason R. Coombs 01 Sep '10

01 Sep '10

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 dependencies. 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 = {'client': 'server'}" 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? Regards, Jason

1 0