[Python-Dev] Re: Patch level versions and new features (Was: Some dull gc stats)

[M.-A. Lemburg]

Barry A. Warsaw wrote:
>>>>>>"MAL" == M  <mal@lemburg.com> writes:
>>>>>
> 
>     >> My suggestion would be to prepend a new directory on the
>     >> standard search path, let's call it site-upgrade for now.  A
>     >> normal "python setup.py install" would still install to
>     >> site-packages, but we'd add a "python setup.py upgrade" command
>     >> that would install to site-upgrade.
> 
>     MAL> +1 (maybe with s/site-upgrade/system-packages)
> 
> I like that: system-packages.
> 
>     MAL> Not sure whether it's already possible or not, but I'd prefer
>     MAL> to keep the install command and have the package provide this
>     MAL> information (site-packages vs. system-packages) as part of
>     MAL> the setup.py or setup.cfg file.
> 
> Ok, yeah.  I think it would be a good idea for the package to somehow
> register itself as an upgrade to an existing system package.  I still
> want the install command to install to site-packages, but whether the
> upgrade happens as an upgrade command or "python setup.py install -U"
> or some other mechanism is up for grabs.

Hmm, maybe I wasn't clear enough: I think that a distutils
package should have a flag in its setup.py which lets distutils
tell whether it's a site package or a system package, e.g.

setup(... pkgtype='site-package' ...)
vs.
setup(... pkgtype='system-package' ...)

(with pkgtype='site-package' as default value if not given)

The user would in both cases type 'python setup.py install'
but the install command would automatically choose the
right target subdir (site-packages/ or system-packages/).

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/