On 2008-03-21 22:21, Phillip J. Eby wrote:
> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>> I guess the only way to support all of these variants is
>> to use a filesystem based approach, e.g. by placing a file
>> with a special extension into some dir on sys.path.
>> The "database" logic could then scan sys.path for these
>> files, read the data and provide an interface to it.
>>
>> All bdist formats would then have to include these files.
>
> That's the idea behind the current version of PEP 262, yes, and I think
> it should be kept.
>
>> A separate FILES section also doesn't seem to be necessary -
>> we could just add one or more entries or the format:
>>
>> CreatesDir abc/
>> CreatesFile abc/xyz1.py
>> CreatesDir abc/def/
>> CreatesFile abc/def/xyz2.py
>> CreatesFile abc/def/xyz3.py
>> CreatesFile abc/def/xyz4.ini
>
> I actually think the size and hash information is good, in order to be
> able to tell if you're looking at an original file. I'm not sure how
> useful the permissions and uid/gid info is. I'm hoping we'll hear from
> anybody who has a use case for that.
You're heading off in the wrong direction: we should not be trying
to rewrite RPM or InnoSetup in Python.
Anything more complicated should be left to tools which are
specifically written to manage complex software setups.
I honestly believe that most people would be happy if we just
provide these two things (and no more):
* install a package from a local archive, a URL or PyPI
* uninstall a package in way that doesn't break other
installed packages
and whatever the mechanism, avoid making any undercover
changes to the Python installation such as adding
.pth files, overriding site.py, etc. - these are
not needed if the tool keeps to the simple task of
installing and uninstalling Python packages.
Examples:
python pypi.py install mypkg-1.0.tgz
python pypi.py install http://www.example.com/mypkg-1.0.tgz
python pypi.py install mypkg-1.0
python pypi.py uninstall mypkg
If there's a dependency problem, the tool should print the
list of other packages it needs. It should not try to install
things automagically.
If a package needs other modules as well, the package docs
can point the user to use e.g.
python pypi.py install mydep1-1.3 mydep2-2.3 mydep4-0.3 mypkg-1.0
instead.
Anything more complicated should be left to specialized
tools such as RPM, apt, MSI or the other such tools out
there - after all the tool should be about Python *package*
installation, not application installation.
We *don't* need the tool to:
* support multiple versions of a package (that's just bound
to cause problems with pickle, isinstance() etc.)
* provide namespace hacking (is a completely separate issue
and can be handled by the packages rather than the install
tool)
* support all kinds of funky version numbers (if a package
wants to participate in the system, the author better
make sure that the version string fits the standard format)
* provide some form of intra-package bus interface (ie.
"entry points" as you call them)
* provide support for keeping whole packages in ZIP files
(doesn't play well with C extensions, clutters up the
sys.path, is read-only, needs special importers, etc. etc. )
* try automatic version matching for required packages
* download things from SourceForge or other sites with special
download mechanisms
* scan websites for links
* make coffee, clean the house, send the kids to school :-)
> And of course, there are still some issues to be resolved regarding
> requirements, package name/version stuff, etc. But we can hash those
> out once we reach a quorum on the Distutils-SIG.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 21 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
