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 searc
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.
Going back and searching titles for 'T
David Lyon wrote:
> All it requires is a few word changes to the documentation to tell
> programmers to put your documentation in "docs"...
There is no current distutils setting to indicate that a particular data
file is actually documentation rather than something else - hence such a
thing *isn't
On Thu, 09 Jul 2009 16:00:41 -0400, Fred Drake wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>> - - docs
>> - - i18n / locales
>
>
> On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote:
>> Unfortunately, the distutils don't currently have a way to specify
>> these.
>
>
> There actually is a
On Fri, 10 Jul 2009 05:53:13 +1000, Nick Coghlan
wrote:
> There are probably all sorts of other useful distinctions which could be
> made. However, that would be a topic for a different PEP - as Tarek
> pointed out, improving distutils is such a huge can of worms that trying
> to tackle all the is
At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
- - docs
- - i18n / locales
On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote:
Unfortunately, the distutils don't currently have a way to specify
these.
There actually is a way to identify documentation files via setup.cfg,
but I don't know if the
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 a
Tres Seaver wrote:
> Nick Coghlan wrote:
>> 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.
>
> Per discussion with Matthias Klose, it would be useful to spli
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 the
-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'
2009/7/9 Eric Smith :
> Yes. I'm just trying to point out that the information in the PEP is
> applicable only to the set of installers that want to work together in some
> integrated way. It doesn't apply to all installers, and I think that's the
> bigger problem.
Interoperability standards are o
P.J. Eby wrote:
At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "setup.py install". It
2009/7/9 Paul Moore :
> I'd like to add a test case using a non-standard PEP 302 importer, but
> that's a small detail.
I've just pushed a PEP 302 importer test case.
The level of boilerplate needed is a bit painful, but it's fine as a
prototype. When we get consensus on some of the remaining det
On Thu, Jul 9, 2009 at 4:18 PM, Paul Moore wrote:
>>
>> There might be a library (and I call dibs on the name "distlib" :) that
>> provides support routines to parse setup.info, but there's no framework
>> involved. And no need for a plugin system.
>
> +1. Now who's going to design & write it?
I
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 "inst
Eric Smith wrote:
> I really don't get this use case of multiple installers trying to
> install the same package. There's just no way that running "yum install
> twisted" and "apt-get install twisted" and "pip install twisted" are
> going to coexist with each other. The best they can do is say "a f
2009/7/9 Tarek Ziadé :
> On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
> Ratnakumar wrote:
>> Other than easy_install/pip, there is also PyPM which is being developed at
>> ActiveState. PyPM is the Python package manager much like what ppm is for
>> ActivePerl.
>>
>
> Great ! besides the RECORD file, any
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
> Other than easy_install/pip, there is also PyPM which is being developed at
> ActiveState. PyPM is the Python package manager much like what ppm is for
> ActivePerl.
>
Great ! besides the RECORD file, anything remark on the PEP from a
PyP
On Thu, Jul 9, 2009 at 9:18 AM, Paul Moore wrote:
> 2009/7/9 Eric Smith :
>> P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
>>>
>>> Or uninstall where the installer is "setup.py install", actually.
>>
>> I think we need to
On Thu, Jul 9, 2009 at 3:07 AM, P.J. Eby wrote:
> At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote:
>>
>> Eric Smith writes:
>>
>> > But I think we've veered into metadata that describes what has been
>> > installed. I don't think that's so useful. As I've said, this is
>> private
>> > to t
On Thu, Jul 9, 2009 at 12:07 AM, Eric Smith wrote:
> Paul Moore wrote:
>>
>> 2009/7/8 P.J. Eby :
>>>
>>> If it were being driven by setuptools, I'd have just implemented it
>>> myself
>>> and presented it as a fait accompli. I can't speak to Tarek's motives,
>>> but
>>> I assume that, as stated in
2009/7/9 Eric Smith :
> P.J. Eby wrote:
>>>
>>> ISTM that the problem that it solves is uninstall in the absence of
>>> the original installer.
>>
>> Or uninstall where the installer is "setup.py install", actually.
>
> I think we need to move away from "setup.py install". It's the antithesis of
>
22 matches
Mail list logo
