[Distutils] EasyInstall: suggested usage patterns

[Phillip J. Eby]

At 12:41 AM 6/16/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>Deployment
>>>
>>>* I have developed a web application.  Maybe it also doesn't have a
>>>distutils script...?
>>
>>Note that with setuptools, a setup script doesn't have to say much 
>>besides metadata like name, version, author, etc.  You can use the 
>>'find_packages()' function to automatically include all packages (perhaps 
>>excepting those that have been somehow marked as being checked out by 
>>'package.py develop'), so it's mostly a matter of listing scripts and such.
>>Note, by the way, that information like author, license, and a number of 
>>other things could easily be defaulted by a configuration file, too, if 
>>set in e.g.  the ~/.pydistutils.cfg file on a per-user basis.
>
>You mean when generating setup.py?  I wouldn't want the setup.py to simply 
>omit these details and then pick them up from a configuration file.  I 
>might forget to explicitly put those values in if that's the case, then 
>someone else will get different values based on their environment.

Don't forget about setup.cfg, which lives alongside setup.py.  I'm assuming 
that you would put in defaults in your ~/.pydistutils.cfg, and then they 
would be used to generate entries in setup.cfg when you create the 
project.  Why not in setup.py?  Because programs can edit setup.cfg more 
easily than they can setup.py.  It would be nice if you could literally use 
a stock setup.py with no human-edited content, at least for "pure" packages 
with no special needs.


>>>  It could, though currently I don't develop one for
>>>my web applications.  Also, I sometimes make hot fixes, especially when
>>>the application is deployed but not yet live.
>>
>>Surely this could be done by deploying a project directory?
>
>You mean, deploy the application as a checkout with the egg-info 
>directory?  That's what I would be inclined to do.  But it should be 
>explicit if this is the recommended way to deploy if you are expecting to 
>do hot fixes.

I just look at it as still being a development environment in that case.


>>>* Some libraries are internal, and so aren't available from a public
>>>location.  Maybe on the web with HTTP auth, though I'm more inclined to
>>>simply keep them in a branch in the private repository.  Or fetch over scp.
>>
>>Sure; EasyInstall also supports "find_links" pages that list links to 
>>source archives or eggs, so you can use this technique to access them 
>>more easily by putting the download pages in your configuration file(s).
>
>This might be useful to list in a ~/.pydistutils.cfg -- I could put the 
>URL to some central page (for my company) that in turn pointed to places 
>in a private repository.  Or even just to internally preferred/tested 
>releases of other people's software (assuming that directory took 
>precedence over PyPI when installing without an explicit version).

EasyInstall only looks on PyPI if it can't find a package that satisfies 
your request via the --find-links.  That's true *even if* you specify a 
version.


>>>* Should I change my require()s to use a specific version of the
>>>libraries, so that I don't accidentally upgrade (/break) the application
>>>when a later application is installed?  How do I manage that process?
>>
>>That won't prevent breakage, if you end up with a conflict between the 
>>versions required by multiple components.  Sadly, I have no silver bullet 
>>for you regarding management.
>
>Well, presumably I've tested my application in development, and I 
>installed specific versions of packages during development.  If I could 
>record the actual versions I installed (some of which had explicitly 
>installed versions, and some which were just the most recent release) then 
>I could duplicate that tested environment later when the most recent 
>versions had changed.

Sure; you can just code the specific required versions into your 
depends.txt.  (Which I'm thinking of renaming to 'requires.txt', btw.)