On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé
wrote:
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 ! be
On Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore wrote:
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
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
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
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
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
>
On 03:28 am, e...@trueblade.com wrote:
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously inst
On 02:55 am, e...@trueblade.com 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 c
At 11:28 PM 7/8/2009 -0400, Eric Smith wrote:
Eventually, I'd like PEP 376 to support system packagers too. So
for example, if you did "apt-get install python-pyqt4", then
running "pip install python-pyqt4" should return without installing
anything .. as RECORD will be part of the .deb previous
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's the
antithesi
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously installed. As for generating
the RECORD fil
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 static metadata. setup.py needs to go awa
Steven D'Aprano wrote:
On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:
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 the installers. If 2 installers want to communicate with
each other about what t
On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore wrote:
If the only driver for this PEP is setuptools, then I'm -1 on it.
Unless someone working on a packaging tool *other* than setuptools (or
setuptools-derived projects) speaks up and says "I have code of my own
which uses distutils, and I would
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 the installers. If 2 installers want to communicate with each other
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 the installers. If 2 installers want to communicate with each other
> about what they've inst
On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:
> 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 the installers. If 2 installers want to communicate with
> each other about what they've installed,
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 the installers. If 2 installers want to communicate with each other
> about what they've installed, then they can agree on
On Thu, Jul 9, 2009 at 7: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/8 Eric Smith :
> I was there, and I've been commenting!
Sorry, I hadn't realised that. Thanks for the correction.
> There might have been more discussion after the language summit and the one
> open space event I went to. But the focus as I recall was static metadata
> and version specific
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 the PEP, the primary driver is supporting the
distutils being able to uninstall
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 the PEP, the primary driver is supporting the
> distutils being able to uninstall things, and
>> Hehe very nice, thanks for the explanation :)
>>
>> (thanks to the others too)
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high
At 01:58 PM 7/8/2009 -0400, Eric Smith wrote:
I really don't see this use case. Supporting multiple installers for
the same file (or even just trying to prevent two installers from
writing the same file)? Wouldn't you be better off just saying an
installer can't overwrite any existing file?
L
At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
2009/7/8 P.J. Eby :
> At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> Who's going to use the APIs based around the RECORD file? Anyone?
>
> The distutils uninstall facility, for starters. easy_install and pip also
> will, eventually.
Is pip gett
P.J. Eby wrote:
At 08:59 AM 7/8/2009 -0400, Eric Smith wrote:
I agree with this. For RPM's, there's a whole other database of what
files were installed. Is it really the intent that a file will be
managed by multiple different installers? That I can install with RPM
but remove with some python
2009/7/8 P.J. Eby :
> At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> Who's going to use the APIs based around the RECORD file? Anyone?
>
> The distutils uninstall facility, for starters. easy_install and pip also
> will, eventually.
Is pip getting this via setuptools, or will it be independe
On Wed, Jul 8, 2009 at 5:11 PM, P.J. Eby wrote:
> At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> An alternative solution would be for the bdist_xxx commands to ignore
>> the RECORD file generated in the temp area, and build its own on the
>> target machine when the installer is run. This is co
At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
Who's going to use the APIs based around the RECORD file? Anyone?
The distutils uninstall facility, for starters. easy_install and pip
also will, eventually.
In all three cases, the use will be in order to avoid overwriting
files belonging to a
At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
An alternative solution would be for the bdist_xxx commands to ignore
the RECORD file generated in the temp area, and build its own on the
target machine when the installer is run. This is conceptuially far
cleaner, it's in line with the implicit assu
2009/7/8 Eric Smith :
> [Any reason you didn't respond to the list? I'd like to continue the
> discussion there. But I'm currently replying just to you.]
No, I just clicked the wrong button. Sorry. Redirecting back to the list.
> Paul Moore wrote:
>>
>> 2009/7/8 Eric Smith :
>>>
>>> I agree with
Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
I have no answer here. But I think we need feedback from the people
who will ultimately be building bdist_xxx formats - Debian packagers,
people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handl
2009/7/8 Antoine Pitrou :
> Paul Moore gmail.com> writes:
>>
>> I have no answer here. But I think we need feedback from the people
>> who will ultimately be building bdist_xxx formats - Debian packagers,
>> people wrting alternate RPM builders, etc.
>
> I think any bdist_xxx command which targets
Paul Moore gmail.com> writes:
>
> I have no answer here. But I think we need feedback from the people
> who will ultimately be building bdist_xxx formats - Debian packagers,
> people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handled package format
2009/7/8 Nick Coghlan :
> Antoine Pitrou wrote:
>> Nick Coghlan gmail.com> writes:
>>> For example, I quite like the concept behind the various ideas for
>>> "location" or "prefix" definitions either in the RECORD file itself or
>>> in a separate PREFIXES file, since such approaches feeds directly
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> For example, I quite like the concept behind the various ideas for
>> "location" or "prefix" definitions either in the RECORD file itself or
>> in a separate PREFIXES file, since such approaches feeds directly in to
>> part b) above.
>
>
Nick Coghlan gmail.com> writes:
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high because
> packaging cross-platform is so messy.
Tarek Ziadé wrote:
> On Wed, Jul 8, 2009 at 7:09 AM, P.J. Eby wrote:
>> So I punned on that in order to imply that nobody who takes on the job of
>> packaging expects to be asked the kind of detailed, unanswerable questions
>> that come with the territory of packaging, or to be subjected to torture
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Eby wrote:
> At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
>> > At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>> >>
>> >> When I started to work on this I didn't realize the gigantic amount of
>> >> work a
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> When I started to work on this I didn't realize the gigantic amount of
>> work and coordination it requires
>
> No one expects the package inquisi
Tarek Ziadé writes:
> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> > No one expects the package inquisition. ;-)
> Sorry, i've looked in the english dictionary but I don't get this one.
I think that far more important than PEP 385 conversion of Roundup and
other utilities to recognize
Tarek Ziadé wrote:
> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
>> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>> When I started to work on this I didn't realize the gigantic amount of
>>> work and coordination it requires
>> No one expects the package inquisition. ;-)
>>
>>
>
> Sorry,
On Tue, 7 Jul 2009 at 23:30, Tarek Ziad? wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziad? wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ?;-
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
>>
>> When I started to work on this I didn't realize the gigantic amount of
>> work and coordination it requires
>
> No one expects the package inquisition. ;-)
>
>
Sorry, i've looked in the english
2009/7/7 Nick Coghlan :
> For *nix, the obvious use case is installing scripts somewhere like
> /usr/bin or /usr/local/bin.
Using distutils' scripts option, they will end up in : sys.exec_path/bin
Another use case I've found in a distro I've installed this afternoon :
setup(..., data_files=[('/
2009/7/7 Paul Moore :
>
> The RECORD file should contain precisely those files that are created
> as part of the install. That's ultimately the point of the file (for
> ownership queries and uninstallation).
>
> Hmm, on the other hand, if foo.py is in the RECORD file, the
> uninstaller should unins
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ;-)
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Tue, Jul 7, 2009 at 2:52 PM, R. David Murray wrote:
> On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
>>
>> 2009/7/7 Ben Finney :
>> [... lots of interesting stuff deleted ...]
>>>
>>> I think it's not the developer's burden to decide *where* such files go;
>>> rather, they should be declaring on
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
I think it's not the developer's burden to decide *where* such files go;
rather, they should be declaring only the *purpose* of these files in
the distribution metadata, and it's up t
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
> I think it's not the developer's burden to decide *where* such files go;
> rather, they should be declaring only the *purpose* of these files in
> the distribution metadata, and it's up to the site-specific installer
> (possibly as
Paul Moore writes:
> The only cases I know where there is reason for a package to store
> paths outside the package directory are:
I think the *only* files that actually belong in the package directory
are the Python modules inside that package. Other files need to be
easily, and automatically,
Paul Moore wrote:
> 2009/7/6 Nick Coghlan :
> - There are *no* guaranteed absolute locations on Windows, so any such
> oddly-located file would require user interaction to work. Certainly
> bdist_wininst and bdist_msi don't do that.
> - My experiments indicate that bdist_{wininst,msi} are broken wi
2009/7/7 M.-A. Lemburg :
> I think you have to differentiate between packages and applications.
Agreed. I believe that only packages should be considered here.
Applications are the focus of tools like py2exe on Windows, and (AIUI)
things like workingenv. These tools should (will) have their own
ap
Paul Moore wrote:
>> I know some people are writing to /etc to add their configuration file
>> on the system,
>>
>> So a real-world example under linux would be:
>>
>> setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
>>
>>
>> That is basically how the examples are shown at:
>>
>> http://docs.
On 6 Jul, 2009, at 20:38, Paul Moore wrote:
- Should distribution names be case insensitive on case insensitive
filesystems? For comparison, module/package names are always case
sensitive even on case insensitive systems.
I'd then go for case sensitive names for distributions as well, just
On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore wrote:
> 2009/7/7 Tarek Ziadé :
>> Unless we define a "drive that contains the python installation" maybe, or
>> the "Program Files" directory
>>
>> would that make sense from a win32 point of view ?
>
> I can't imagine that it would be useful in practic
2009/7/7 Tarek Ziadé :
> Unless we define a "drive that contains the python installation" maybe, or
> the "Program Files" directory
>
> would that make sense from a win32 point of view ?
I can't imagine that it would be useful in practice.
> I know some people are writing to /etc to add their co
2009/7/7 Paul Moore :
> 2009/7/6 Nick Coghlan :
>> I'd add one more question to the list: is allowing backslash separated
>> names in the RECORD file actually a good idea, or would it be better to
>> always use forward slashes?
>
> They do always use forward slashes.
>
>> For the other questions, I
2009/7/7 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>>
>>> As promised, here are some open questions on PEP 376.
>>>
>>> - Will the public API names be changed from *egginfo* to *metadata*?
>>
>> +1 (FWIW, 'metadata' is what pkg_resources API refers to this
2009/7/6 Nick Coghlan :
> I'd add one more question to the list: is allowing backslash separated
> names in the RECORD file actually a good idea, or would it be better to
> always use forward slashes?
They do always use forward slashes.
> For the other questions, I don't have anything much to add
2009/7/6 P.J. Eby :
> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>
>> As promised, here are some open questions on PEP 376.
>>
>> - Will the public API names be changed from *egginfo* to *metadata*?
>
> +1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff
> as.)
Thanks.
(I cancelled sending this the first time, so apologies if a half-written
version turns up)
Paul Moore wrote:
> As promised, here are some open questions on PEP 376.
I'd add one more question to the list: is allowing backslash separated
names in the RECORD file actually a good idea, or would it be
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of
stuff as.)
- What precisely are the use cases for
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
- What precisely are the use cases for absolute path names? Concrete
examples are needed. With the current spec, some things can go wrong
(e.g., see below), so we need real u
73 matches
Mail list logo
