Re: [Python-Dev] PEP 376 - Open questions
2009/7/9 Nick Coghlan : > Paul Moore wrote: >> - some cases are not simple, and it's not clear to me how useful >> "nearly always accurate" data will be > > Since the accuracy can always be checked against the filesystem, I think > the metadata is useful even if not 100% reliable. Applications that need > the extra assurance (such as the distutils uninstaller itself) can check > the filesytem and complain when it differs from what it is claimed in > the package metadata. The inaccuracy I was thinking of was that if distribution X's RECORD doesn't mention file Y, the implication is that X doesn't "own" Y. There's no way of checking this against the filesystem - RECORD is the only place that says that X owns Y. I was thinking in terms of "does anyone else mind if I delete/overwrite this file?" queries, not uninstallation. > One thing that did occur to me based on this - do we want the format to > support designation of files (such as config files) that *shouldn't* be > uninstalled along with everything else? Or are we happy with not > mentioning the file in RECORD at all as the means of supporting that use > case? No. In my view, the uninstall feature is a relatively minor issue - people who want uninstall facilities generally use system packages (or complain that easy_install doesn't support uninstallation :-)). They aren't using setup.py install. (Of course, my experience is minimal in this regard, so maybe I'm wrong). Remember that the PEP says "Distutils will provide a **very basic** uninstall function" (my emphasis). Unless I'm misunderstanding, no-one is intending to use the new distutils uninstall feature in their own package manager (bdist_wininst, RPM, apt, ...) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>> Also,
>> >>> why should the RECORD file be generated at all by bdist* commands?
>> >> bdist commands that use "install --root" will get it as a side effect,
>> >> so they don't have to do anything special. They needn't even generate
>> >> the PREFIXES, if PREFIXES is also generated by "install --root", and
>> >> omits the root from the prefixes written. In other words, most bdist
>> >> tools wouldn't change. bdist_wininst and bdist_msi might need to
>> >> regenerate PREFIXES at actual installation time, but AFAIK those are
>> >> the
>> >> only ones. (And the spec would allow for the possibility that a
>> >> PREFIXES file can be incorrect.)
>> >
>> > I haven't seen any suggestions for handling non-relative paths that are
>> > cleaner than this. The distutils based list that Tarek posted also gives
>> > a good "starter set" of supported entries in the PREFIXES file:
>> >
>> > PURELIB=
>> > PLATLIB=
>> > HEADERS=
>> > SCRIPTS=
>> > DATA=
>> >
>> > The question then would be whether relative paths should be handled
>> > directly in the RECORD file (as in the current PEP) or by writing a "."
>> > into PREFIXES to indicate relative paths.
I like the idea of a separated PREFIXES file, then using variables in
the RECORD file.
While this doesn't change anything code-wise, we can keep that way two
csv-browsable files.
>>
>> Per discussion with Matthias Klose, it would be useful to split out the
>> following prefixes for "special" kinds of data:
>>
>> - - docs
>> - - i18n / locales
>
> Unfortunately, the distutils don't currently have a way to specify these. I
> think we'll need to use only the ones that are distutils install targets at
> first, but of course the format is extensible.
>
> OTOH, one supposed that at least the 'data_files' setup argument could be
> enhanced to allow a data type flag, that would then be used as a prefix name
> for those files, with a fallback to the DATA prefix if there isn't one
> specified. But that's something that will require tagging support in the
> install_data command. As it is, refactoring the distutils to track prefixes
> for the RECORD file is probably going to be... challenging. ;-)
yes, if we want to provide extensibility, a new prefix that is used by
a developer in its distribution
will have to be provided for all platforms, so distutils can build the
proper RECORD file
by querying the path that corresponds to the platform it runs on.
In other words, if a data type flag is provided in data_files, the
list of absolute paths
per key in distutils.command.install.INSTALL_SCHEMES should be
provided with it.
This could be done with a new 'extra_prefixes' argument for example,
provided with the 'data_files',
that would let distutils extend INSTALL_SCHEMES on the fly
setup(
...
data_files={'i18n': ['en.po', 'fr.po']},
extra_prefixes={'i18n': {'unix_prefix': '/somewhere',
'mac': '/Application/right/here'}
...
)
But then data_files could maybe be left alone (that's specific to
'data' after all)
and a new option created.
In any case that would be a great solution to avoid 'wild absolute
path' and be sure
that the developer thinks about where each fil of his distrbution
goes, depending
on the plaftorm.
While debian packagers and al might not use it to re-package python
distributions in debian
packages, I am sure they will like it very much because it helps
identifiying what the developer
wanted to do with these "data" files.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
-On [20090710 15:32], Tarek Ziadé ([email protected]) wrote: >setup( >... >data_files={'i18n': ['en.po', 'fr.po']}, >extra_prefixes={'i18n': {'unix_prefix': '/somewhere', > 'mac': '/Application/right/here'} > ... > ) As an aside: Where i18n above would sooner be called 'locale' rather than i18n, since i18n is only providing software functionality for supporting localization. So in that sense L10n would be better, but locale is quite a defacto standard in many projects. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B In every colour there's the Light... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (07/03/09 - 07/10/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2245 open (+32) / 16035 closed (+17) / 18280 total (+49)
Open issues with patches: 894
Average duration of open issues: 660 days.
Median duration of open issues: 414 days.
Open Issues Breakdown
open 2215 (+32)
pending30 ( +0)
Issues Created Or Reopened (52)
___
multiprocessing: BaseManager.from_address documented but doesn't 07/09/09
http://bugs.python.org/issue3518reopened jnoller
logging.basicConfig(level='DEBUG', ... and setLevel("DEBUG") res 07/06/09
http://bugs.python.org/issue6314reopened r.david.murray
patch
distutils compiler switch ignored07/08/09
http://bugs.python.org/issue6377reopened tarek
patch
Dictionaries should support __add__ 07/04/09
CLOSED http://bugs.python.org/issue6410reopened ezio.melotti
3.1 not functional 07/03/09
CLOSED http://bugs.python.org/issue6411created element.effect
Titlecase as defined in Unicode Case Mappings not followed 07/03/09
http://bugs.python.org/issue6412created christoph
patch
incorrect log level in distutlis.dist for announce 07/04/09
CLOSED http://bugs.python.org/issue6413created tarek
struct module : processor endianness descriptions misleading 07/04/09
http://bugs.python.org/issue6414created kmag
easy
warnings.warn segfaults on bad formatted string 07/04/09
http://bugs.python.org/issue6415created wiesenth
patch
Failed to compile selectmodule.c on windows (trunk) 07/04/09
CLOSED http://bugs.python.org/issue6416created ocean-city
easy
multiprocessing Process examples: print and getppid 07/04/09
http://bugs.python.org/issue6417created mnewman
unittest.TestProgram change breaks nose 07/04/09
http://bugs.python.org/issue6418created jpellerin
patch
Broken test_kqueue.py on OpenBSD 07/04/09
http://bugs.python.org/issue6419created henry.precheur
Fix warning in nismodule.c on OpenBSD07/04/09
CLOSED http://bugs.python.org/issue6420created henry.precheur
patch
errors in docs re module initialization vs self arg to functions 07/04/09
http://bugs.python.org/issue6421created aleax
easy
timeit called from within Python should allow autoranging07/05/09
http://bugs.python.org/issue6422created scott_daniels
patch
The cgi docs should advertize using "in" instead of "has_key"07/05/09
http://bugs.python.org/issue6423created cito
patch
Idle3 crashing when using completion 07/05/09
CLOSED http://bugs.python.org/issue6424created tcourbon
imaplib.IMAP4.fetch() is missing documentation for message_set p 07/06/09
CLOSED http://bugs.python.org/issue6425created Sjoerder
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
At 03:31 PM 7/10/2009 +0200, Tarek Ziadé wrote:
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>> Also,
>> >>> why should the RECORD file be generated at all by bdist* commands?
>> >> bdist commands that use "install --root" will get it as a side effect,
>> >> so they don't have to do anything special. They needn't even generate
>> >> the PREFIXES, if PREFIXES is also generated by "install --root", and
>> >> omits the root from the prefixes written. In other words, most bdist
>> >> tools wouldn't change. bdist_wininst and bdist_msi might need to
>> >> regenerate PREFIXES at actual installation time, but AFAIK those are
>> >> the
>> >> only ones. (And the spec would allow for the possibility that a
>> >> PREFIXES file can be incorrect.)
>> >
>> > I haven't seen any suggestions for handling non-relative paths that are
>> > cleaner than this. The distutils based list that Tarek posted also gives
>> > a good "starter set" of supported entries in the PREFIXES file:
>> >
>> > PURELIB=
>> > PLATLIB=
>> > HEADERS=
>> > SCRIPTS=
>> > DATA=
>> >
>> > The question then would be whether relative paths should be handled
>> > directly in the RECORD file (as in the current PEP) or by writing a "."
>> > into PREFIXES to indicate relative paths.
I like the idea of a separated PREFIXES file, then using variables in
the RECORD file.
Please note that my proposal intentionally omitted "variables", but
instead used a separate column to designate the prefix. This allows
some guarantees regarding path sanity that could otherwise be abused,
like combining prefixes or inserting them in the middle of paths. In
this way, the formal conversion of a path would be
os.path.join(PREFIX, *relative_path.split('/')), rather than a
variable expansion.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search error on tracker?
Martin v. Löwis wrote: Terry Reedy wrote: Before posting http://bugs.python.org/issue6453 I searched the tracker for 'bool TypeError' to avoid making a duplicate report. A few irrelevant hits were return but not the important one http://bugs.python.org/issue6428 which was the one I needed to find. When I search for 'bool TypeError', #6428 shows up. Are you sure you had been searching for closed reports as well? Un no. Thanks. Perhaps that field should default to 'don't care' like all the others. Sorry for the noise. Terry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mercurial: tag generation incorrect
According to http://hg.python.org/cpython/tags?revcount=50 the tag r301 belongs to revision be32850b093f. However, this is really r69557, which was not tagged. be32850b093f is listed as having a child revision, 52b0a279fec6, and ISTM that *this* should be the revision that got tagged. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial: tag generation incorrect
> be32850b093f is listed > as having a child revision, 52b0a279fec6, and ISTM that *this* > should be the revision that got tagged. I think the tag is correct. Note that the concept of tagging is different in Mercurial, where a tag can only refer to a revision previous to the one where it is inserted in .hgtags. If I understand correctly, all relevant tagging revisions from SVN are replaced by Mercurial revisions setting tags, which then refer to their immediate predecessors. - Hagen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
