Le vendredi 03 octobre 2008 à 15:57 +1300, Greg Ewing a écrit :
On Thu, Oct 02, 2008 at 01:20:45PM +0200, Josselin Mouette wrote:
Sorry, but things don’t work this way. Anything that is *not* a .py file
should not land in the python module directories.
So where *should* they go, on
On Wed, Oct 01, 2008 at 09:33:52PM -0700, Toshio Kuratomi wrote:
Note that Debian has done a lot of neat things with python source
recent(ish). Josselin, Matthias, and some of the other Debian devs
could tell us if .py files get installed to /usr/share there.
Currently the two helper tools
Phillip J. Eby wrote:
I think install tools should handle it and keep it out of developers'
hair. We should of course distinguish configuration and other
writable data from static data, not to mention documentation. Any
other file-related info is going to have to be optional, if that. I
Le mercredi 01 octobre 2008 à 19:59 -0400, Phillip J. Eby a écrit :
locale/{message catalogs for various languages} -- These are binary
files that contain strings that the user may see when a message is
given. These, I think are data.
I lean the other way, since they're not editable.
-On [20081002 13:20], Josselin Mouette ([EMAIL PROTECTED]) wrote:
Locale data should be shipped in standard form, in /usr/share/locale.
Again, Python is not the only thing you need to think of.
Linux is not the only thing to think of by stating /usr/share/locale. :P
I guess ${PREFIX}/share/locale
Le jeudi 02 octobre 2008 à 15:33 +1200, Greg Ewing a écrit :
Toshio Kuratomi wrote:
nod this is what I was afraid of. This is definitely not a definition
of resource-only that has meaning for Linux distributions. None of the
data in /usr/share is user-modifiable
In that case it must
Le jeudi 02 octobre 2008 à 13:25 +0200, Jeroen Ruigrok van der Werven a
écrit :
-On [20081002 13:20], Josselin Mouette ([EMAIL PROTECTED]) wrote:
Locale data should be shipped in standard form, in /usr/share/locale.
Again, Python is not the only thing you need to think of.
Linux is not the
Josselin Mouette wrote:
I don’t understand why you want to make it so complicated. All you need
is a way to specify directories where different kinds of files land and
a simple API to retrieve the file names/contents. Then, you can ship the
files at the place you like in eggs, and we can ship
-On [20081002 13:29], Josselin Mouette ([EMAIL PROTECTED]) wrote:
There’s definitely no problem with shipping them in an egg, as long as
it is possible to ship them at standard locations.
Standard according to whom though?
Contrary to many Linux systems, for example, the BSDs tend to install
Le jeudi 02 octobre 2008 à 13:35 +0200, Jeroen Ruigrok van der Werven a
écrit :
-On [20081002 13:29], Josselin Mouette ([EMAIL PROTECTED]) wrote:
There’s definitely no problem with shipping them in an egg, as long as
it is possible to ship them at standard locations.
Standard according to
At 07:40 PM 10/2/2008 +0900, David Cournapeau wrote:
Phillip J. Eby wrote:
I think install tools should handle it and keep it out of developers'
hair. We should of course distinguish configuration and other
writable data from static data, not to mention documentation. Any
other
On Wed, Oct 01, 2008 at 09:33:52PM -0700, Toshio Kuratomi wrote:
Note that Debian has done a lot of neat things with python source
recent(ish). Josselin, Matthias, and some of the other Debian devs
could tell us if .py files get installed to /usr/share there.
One of the current options in
On Thu, Oct 02, 2008 at 01:20:45PM +0200, Josselin Mouette wrote:
Sorry, but things don’t work this way. Anything that is *not* a .py file
should not land in the python module directories. This is utter abuse of
a loophole of the implementation, and I can’t think of another language
that
Phillip J. Eby wrote:
At 07:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
In terms of implementation I'd much rather see something less centered
on the egg being the right way and the filesystem being a secondary
concern.
Eggs don't have anything to do with it; in Python, it's simply common
On Thu, Oct 02, 2008 at 10:05:49AM -0400, Phillip J. Eby wrote:
I don't see how this is remotely relevant to how Python works or how
people use (and have used) Python over the decades. Data files in
package directories is something I've seen in Python since, oh, 1997 or
so. If it were a
At 08:08 PM 10/2/2008 +0100, Floris Bruynooghe wrote:
On Thu, Oct 02, 2008 at 10:05:49AM -0400, Phillip J. Eby wrote:
I don't see how this is remotely relevant to how Python works or how
people use (and have used) Python over the decades. Data files in
package directories is something I've
Jeroen Ruigrok van der Werven wrote:
-On [20081002 13:29], Josselin Mouette ([EMAIL PROTECTED]) wrote:
There’s definitely no problem with shipping them in an egg, as long as
it is possible to ship them at standard locations.
Standard according to whom though?
I think the idea is to *define*
Phillip J. Eby wrote:
Where data files are concerned, however, a developer should only need to
distinguish between read-only, read-write, and samples, because any
finer-grained distinction that relies on platform-specific concepts
(like locale directories) is probably going to be error-prone.
On Thu, Oct 02, 2008 at 01:20:45PM +0200, Josselin Mouette wrote:
Sorry, but things don’t work this way. Anything that is *not* a .py file
should not land in the python module directories.
So where *should* they go, on platforms where there is
no defined place for such things? And how can the
At 03:25 PM 10/3/2008 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
Where data files are concerned, however, a developer should only
need to distinguish between read-only, read-write, and samples,
because any finer-grained distinction that relies on
platform-specific concepts (like locale
Ben Finney wrote:
I'm not sure exactly what you mean by “do like autoconf”. Can you
please describe exactly what behaviour you are envisaging, so that we
don't all have a different interpretation of what “like autoconf”
means ?
Not autoconf, but the whole autotools suite (I think you need to
You guys are fairly into you debate so hopefully I don't interject
something that's already been gone over :-)
Chris Withers wrote:
Matthias Klose wrote:
Install debian and get back to productive tasks.
This is an almost troll-like answer.
See page 35 of the presentation.
I disagree. You
Le mercredi 01 octobre 2008 à 11:00 -0700, Toshio Kuratomi a écrit :
1) The heuristic encourages bad practices. Versions need to be parsed
by computer programs (package managers, scripts that maintain
repositories, etc). Not all of those are written in python. Having
things other than
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
We need to be able to mark locale, config, and data files in
the metadata.
Sure... and having a standard for specifying that kind of
application/system-level install stuff is great; it's just entirely
outside the
At 09:40 PM 10/1/2008 +0200, Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
We need to be able to mark locale, config, and data files in
the metadata.
Sure... and having a standard for specifying that kind of
application/system-level
Phillip J. Eby wrote:
At 11:00 AM 10/1/2008 -0700, Toshio Kuratomi wrote:
I have no love for how pkg_resources implements this (including the API)
but the idea of retrieving data files, locales, config files, etc from
an API is good. For packages to be coded that conform to the File
Hierachy
Phillip J. Eby wrote:
At 09:40 PM 10/1/2008 +0200, Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
We need to be able to mark locale, config, and data files in
the metadata.
Sure... and having a standard for specifying that kind of
Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
To be clear, I mean here that a file (as opposed to a resource) is
something that the user is expected to be able to read or copy, or
modify. (Whereas a resource is something that is entirely
At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
resources, as I said needs to be defined. You're saying here that a
resource is something internal to the library. A file is something
that a user can read, copy, or modify.
I should probably clarify that I mean unmediated by the
Phillip J. Eby wrote:
At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
resources, as I said needs to be defined. You're saying here that a
resource is something internal to the library. A file is something
that a user can read, copy, or modify.
I should probably clarify that I mean
At 07:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote:
In terms of implementation I'd much rather see something less centered
on the egg being the right way and the filesystem being a secondary
concern.
Eggs don't have anything to do with it; in Python, it's simply common
sense to put static
Greg Ewing wrote:
Toshio Kuratomi wrote:
nod this is what I was afraid of. This is definitely not a definition
of resource-only that has meaning for Linux distributions. None of the
data in /usr/share is user-modifiable
In that case it must be there because it's
Toshio Kuratomi [EMAIL PROTECTED] writes:
3) /usr/share has two purposes/criteria[1]_: architecture
independent and datafiles. /usr/lib has two criteria[2]_:
architecture independent and libraries. With .py{,c,o} we have both
architecture indepedence and a library. So the criteria is in
Matthias Klose wrote:
Install debian and get back to productive tasks.
This is an almost troll-like answer.
See page 35 of the presentation.
I disagree. You could think of Packages are Pythons Plugins (taken
from page 35) as a troll-like statement as well.
You're welcome to your (incorrect)
Ian Bicking wrote:
Rick Warner wrote:
Actually, PyPI is replicated. See, for example,
http://download.zope.org/simple/.
It may be that some of the mirrors should be better advertised.
A half-hearted effort. at best, after the problems last year. When I
configure a CPAN client (once per
Matthias Klose wrote:
Your paper gives a nice overview of the shortcomings of each of the
build/distribution systems. From an (os) distributors point of view I
would add som things (also posted in [1]). [snip]
I think it would be worthwhile to have one location to put those
requirements.
On Thu, Sep 25, 2008 at 4:13 PM, David Cournapeau
[EMAIL PROTECTED] wrote:
Matthias Klose wrote:
Your paper gives a nice overview of the shortcomings of each of the
build/distribution systems. From an (os) distributors point of view I
would add som things (also posted in [1]). [snip]
On Thu, Sep 25, 2008 at 4:52 PM, Tarek Ziadé [EMAIL PROTECTED] wrote:
On Thu, Sep 25, 2008 at 4:13 PM, David Cournapeau
[EMAIL PROTECTED] wrote:
Matthias Klose wrote:
Your paper gives a nice overview of the shortcomings of each of the
build/distribution systems. From an (os)
On Wed, Sep 24, 2008 at 2:24 AM, Jim Fulton [EMAIL PROTECTED] wrote:
On Sep 23, 2008, at 6:42 PM, Rick Warner wrote:
Jim Fulton wrote:
On Sep 23, 2008, at 5:44 PM, Rick Warner wrote:
Jeff Younker wrote:
I have to say, as a developer, and a system administrator, I like
setuptools.
Chris Withers writes:
(I'll be CC'ing the distutils sig in to these replies as this discussion
probably belongs there...)
Nicolas Chauvat wrote:
The slides for my two talks can be found here:
http://www.simplistix.co.uk/presentations
Python Package Management Sucks
Install
(I'll be CC'ing the distutils sig in to these replies as this discussion
probably belongs there...)
Nicolas Chauvat wrote:
The slides for my two talks can be found here:
http://www.simplistix.co.uk/presentations
Python Package Management Sucks
Install debian and get back to productive
John Pinner wrote:
To me, setup tools is missing two essential features of a package
management system:
1. Dependency management
I'm pretty sure setuptools does this.
It could probably do a better job of checking version and dependency
clashes, but provided there are none of these, it
On Tue, Sep 23, 2008 at 12:37 PM, Chris Withers [EMAIL PROTECTED]wrote:
(I'll be CC'ing the distutils sig in to these replies as this discussion
probably belongs there...)
Nicolas Chauvat wrote:
The slides for my two talks can be found here:
http://www.simplistix.co.uk/presentations
I have to say, as a developer, and a system administrator, I like
setuptools. It does
what I need. Could it be better? Sure. For what I use python for on
a day-to-day
basis it makes my life a thousand times better than it was before
setuptools. Nothing
ruins your day more than spending
Jeff Younker wrote:
I have to say, as a developer, and a system administrator, I like
setuptools. It does
what I need. Could it be better? Sure. For what I use python for on
a day-to-day
basis it makes my life a thousand times better than it was before
setuptools. Nothing
ruins your day
Jim Fulton wrote:
On Sep 23, 2008, at 5:44 PM, Rick Warner wrote:
Jeff Younker wrote:
I have to say, as a developer, and a system administrator, I like
setuptools. It does
what I need. Could it be better? Sure. For what I use python for
on a day-to-day
basis it makes my life a thousand
On Sep 23, 2008, at 6:42 PM, Rick Warner wrote:
Jim Fulton wrote:
On Sep 23, 2008, at 5:44 PM, Rick Warner wrote:
Jeff Younker wrote:
I have to say, as a developer, and a system administrator, I like
setuptools. It does
what I need. Could it be better? Sure. For what I use python
Rick Warner wrote:
Actually, PyPI is replicated. See, for example,
http://download.zope.org/simple/.
It may be that some of the mirrors should be better advertised.
A half-hearted effort. at best, after the problems last year. When I
configure a CPAN client (once per user) I create a list
48 matches
Mail list logo
