On Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore p.f.mo...@gmail.com 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
On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé ziade.ta...@gmail.com
wrote:
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumarsridh...@activestate.com wrote:
Other than easy_install/pip, there is also PyPM which is being
developed at
ActiveState. PyPM is the Python package manager much
2009/7/9 Eric Smith e...@trueblade.com:
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 Thu, Jul 9, 2009 at 3:07 AM, P.J. Ebyp...@telecommunity.com 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
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumarsridh...@activestate.com 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
2009/7/9 Tarek Ziadé ziade.ta...@gmail.com:
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumarsridh...@activestate.com 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.
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 file
I'm
2009/7/9 Paul Moore p.f.mo...@gmail.com:
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
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's
2009/7/9 Eric Smith e...@trueblade.com:
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
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
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Ebyp...@telecommunity.com wrote:
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the
Tarek Ziadé wrote:
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Ebyp...@telecommunity.com 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
Nick Coghlan ncoghlan at 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
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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.
I
2009/7/8 Nick Coghlan ncogh...@gmail.com:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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
Paul Moore p.f.moore at 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
2009/7/8 Antoine Pitrou solip...@pitrou.net:
Paul Moore p.f.moore at 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
Antoine Pitrou wrote:
Paul Moore p.f.moore at 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
2009/7/8 Eric Smith e...@trueblade.com:
[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
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
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
On Wed, Jul 8, 2009 at 5:11 PM, P.J. Ebyp...@telecommunity.com 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
2009/7/8 P.J. Eby p...@telecommunity.com:
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
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
At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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,
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?
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 because
2009/7/8 P.J. Eby p...@telecommunity.com:
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
Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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
2009/7/8 Eric Smith e...@trueblade.com:
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
On Thu, Jul 9, 2009 at 7:07 AM, Eric Smithe...@trueblade.com wrote:
Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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
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, 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,
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
On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore p.f.mo...@gmail.com 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
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
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 away.
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 file,
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
antithesis
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 previously
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
2009/7/7 Paul Moore p.f.mo...@gmail.com:
2009/7/6 P.J. Eby p...@telecommunity.com:
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
2009/7/7 Paul Moore p.f.mo...@gmail.com:
2009/7/6 Nick Coghlan ncogh...@gmail.com:
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.
2009/7/7 Tarek Ziadé ziade.ta...@gmail.com:
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
On Tue, Jul 7, 2009 at 10:33 AM, Paul Moorep.f.mo...@gmail.com wrote:
2009/7/7 Tarek Ziadé ziade.ta...@gmail.com:
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
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
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:
2009/7/7 M.-A. Lemburg m...@egenix.com:
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)
Paul Moore wrote:
2009/7/6 Nick Coghlan ncogh...@gmail.com:
- 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}
Paul Moore p.f.mo...@gmail.com 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,
2009/7/7 Ben Finney ben+pyt...@benfinney.id.au:
[... 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
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
2009/7/7 Ben Finney ben+pyt...@benfinney.id.au:
[... 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
On Tue, Jul 7, 2009 at 2:52 PM, R. David Murrayrdmur...@bitdance.com wrote:
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
2009/7/7 Ben Finney ben+pyt...@benfinney.id.au:
[... lots of interesting stuff deleted ...]
I think it's not the developer's burden to decide *where* such files go;
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
2009/7/7 Paul Moore p.f.mo...@gmail.com:
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
2009/7/7 Nick Coghlan ncogh...@gmail.com:
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 :
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com 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
On Tue, 7 Jul 2009 at 23:30, Tarek Ziad? wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com 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
Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com 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. ;-)
Tarek Ziadé writes:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com 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
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com 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
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
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
(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
2009/7/6 P.J. Eby p...@telecommunity.com:
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
2009/7/6 Nick Coghlan ncogh...@gmail.com:
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
67 matches
Mail list logo
