At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote: >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.
I'm making the assumption that the author(s) of PEP 262 had good reason for including what they did, rather than assuming that we should start the entire process over from scratch. >Anything more complicated should be left to tools which are >specifically written to manage complex software setups. Tools which will need this data, in order to do their work. Hence, the reason for standardizing the data, instead of the tool(s). >[snip long list of features, both desired and undesired] Actually, *all* of these features are out of scope for stdlib development, because I'm not proposing including *any* tools for this in the stdlib, apart from distutils install and bdist_* support. I'm proposing, rather, that we finish the vision of PEP 262, of having a standard specification that *all* tools will abide by -- including rpm, dpkg, and what-have-you. Since *all* of these tools need to abide by that specification, their requirements will need to be considered in the formulation of the spec. And as I said, I'll be happy if all we do is get the distutils to abide by the spec for 2.6, even if it means we don't get an uninstall tool. That can always be installed later using Guido's bootstrap tool. :) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
