Ian Bicking wrote:
> Paul Moore wrote:
>> My feeling, by the way, is that "system packagers" are the more
>> relevant group on Linux/Unix (where most users install Python modules
>> via system packages, or else they are developers)
>
> I think this is part of why I don't understand the system pack
On Fri, Oct 10, 2008 at 02:34:30PM -0400, Ian Bicking wrote:
> Developers shouldn't use system packages, it just doesn't
> make any sense to have that intermediation.
I don't agree. I work as a developer/scientist in a lab.
I develop algorithms that sometimes will never be used on another box
Ian Bicking wrote:
> I think this is part of why I don't understand the system packager
> perspective. Developers shouldn't use system packages, it just
> doesn't make any sense to have that intermediation.
I can't see why you would think that. Of course it makes sense to have
that intermediation
On Fri, Oct 10, 2008 at 10:56:02PM +0300, Marius Gedminas wrote:
> On Fri, Oct 10, 2008 at 02:34:30PM -0400, Ian Bicking wrote:
> > Paul Moore wrote:
> > >My feeling, by the way, is that "system packagers" are the more
> > >relevant group on Linux/Unix (where most users install Python modules
> > >
On Fri, Oct 10, 2008 at 02:34:30PM -0400, Ian Bicking wrote:
> Paul Moore wrote:
> >My feeling, by the way, is that "system packagers" are the more
> >relevant group on Linux/Unix (where most users install Python modules
> >via system packages, or else they are developers)
>
> I think this is part
2008/10/10 Ian Bicking <[EMAIL PROTECTED]>:
> Paul Moore wrote:
>>
>> My feeling, by the way, is that "system packagers" are the more
>> relevant group on Linux/Unix (where most users install Python modules
>> via system packages, or else they are developers)
>
> I think this is part of why I don't
Paul Moore wrote:
My feeling, by the way, is that "system packagers" are the more
relevant group on Linux/Unix (where most users install Python modules
via system packages, or else they are developers)
I think this is part of why I don't understand the system packager
perspective. Developers
Le mardi 07 octobre 2008 à 19:25 -0400, Phillip J. Eby a écrit :
> At 12:43 AM 10/8/2008 +0200, Josselin Mouette wrote:
> >What I am afraid of is that, by adding just another layer, you will
> >introduce new problems while fixing existing ones. Currently we already
> >have a hard time maintaining a
Phillip J. Eby wrote:
>
> Sorry, what is pkg-config?
http://pkg-config.freedesktop.org/wiki/
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
At 12:43 AM 10/8/2008 +0200, Josselin Mouette wrote:
Le mardi 07 octobre 2008 à 16:51 -0400, Phillip J. Eby a écrit :
> >If you write a tool to do that, why not make it simply move files
> >properly and let the code locate them, instead of adding yet another
> >layer on top of the existing stuf
Le mardi 07 octobre 2008 à 16:51 -0400, Phillip J. Eby a écrit :
> >If you write a tool to do that, why not make it simply move files
> >properly and let the code locate them, instead of adding yet another
> >layer on top of the existing stuff? The tool will not be more
> >complicated this way.
>
2008/10/7 Phillip J. Eby <[EMAIL PROTECTED]>:
> At 10:04 AM 10/7/2008 +0100, Paul Moore wrote:
>>
>> 2008/10/7 Phillip J. Eby <[EMAIL PROTECTED]>:
>> > You can see that this is also what I did in the design of easy_install
>> > and
>> > setuptools, except that in that effort I only considered devel
At 08:58 PM 10/7/2008 +0200, Josselin Mouette wrote:
Le mardi 07 octobre 2008 à 14:40 -0400, Phillip J. Eby a écrit :
> At 09:57 AM 10/7/2008 +0200, Josselin Mouette wrote:
> >Symlinks are a real pain to handle. We can use them transparently
> >for .pyc files, but if we want to relocate data fi
Le mardi 07 octobre 2008 à 14:40 -0400, Phillip J. Eby a écrit :
> At 09:57 AM 10/7/2008 +0200, Josselin Mouette wrote:
> >Symlinks are a real pain to handle. We can use them transparently
> >for .pyc files, but if we want to relocate data files to some other
> >directories, currently it has to be
At 09:57 AM 10/7/2008 +0200, Josselin Mouette wrote:
Le lundi 06 octobre 2008 à 21:33 -0400, Phillip J. Eby a écrit :
> >Does this mean actively avoiding an API that would allow developers to
> >access certain types of data files (I'm thinking of the discussion
> >about locale data and not putt
At 10:04 AM 10/7/2008 +0100, Paul Moore wrote:
2008/10/7 Phillip J. Eby <[EMAIL PROTECTED]>:
> In the case of BUILDS, I propose to do the same: define a standard whose
> cost/benefit ratios are ideally balanced for each participant. This does
> not, by the way, mean that everybody ends up with t
Le mardi 07 octobre 2008 à 10:02 -0400, Jean-Paul Calderone a écrit :
> The expectations of the Nevow developers was that a file included in Nevow,
> nevow_widget.py, would be installed to
>
> /usr/lib/python2.5/site-packages/twisted/plugins/nevow_widget.py
This expectation is wrong. You’re shi
On Tue, 07 Oct 2008 15:19:57 +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote:
Le mardi 07 octobre 2008 à 08:58 -0400, Jean-Paul Calderone a écrit :
I don't think the details of the plugin system are relevant to the topic
under discussion here. The installation requirements are not unusual for
Le mardi 07 octobre 2008 à 08:58 -0400, Jean-Paul Calderone a écrit :
> I don't think the details of the plugin system are relevant to the topic
> under discussion here. The installation requirements are not unusual for
> the most part - that a directory full of .py files be copied to the install
On Tue, 7 Oct 2008 13:12:03 +0100, Floris Bruynooghe <[EMAIL PROTECTED]> wrote:
On Tue, Oct 07, 2008 at 08:01:28AM -0400, Jean-Paul Calderone wrote:
On Tue, 07 Oct 2008 09:57:56 +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote:
Case 2: twisted. Plugins, consisting of a few .py files, are ship
On Tue, Oct 07, 2008 at 08:01:28AM -0400, Jean-Paul Calderone wrote:
> On Tue, 07 Oct 2008 09:57:56 +0200, Josselin Mouette <[EMAIL PROTECTED]>
> wrote:
>>
>> Case 2: twisted. Plugins, consisting of a few .py files, are shipped in
>> a plugins/ subdirectory, and its content is dynamically added to
On Tue, 07 Oct 2008 09:57:56 +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote:
Case 2: twisted. Plugins, consisting of a few .py files, are shipped in
a plugins/ subdirectory, and its content is dynamically added to
sys.path after some sanity checks (which fail when you add namespace
packages).
2008/10/7 Phillip J. Eby <[EMAIL PROTECTED]>:
> In the case of BUILDS, I propose to do the same: define a standard whose
> cost/benefit ratios are ideally balanced for each participant. This does
> not, by the way, mean that everybody ends up with the same cost/benefit
> ratio; it simply means tha
Le lundi 06 octobre 2008 à 21:33 -0400, Phillip J. Eby a écrit :
> >Does this mean actively avoiding an API that would allow developers to
> >access certain types of data files (I'm thinking of the discussion
> >about locale data and not putting anything else but .py/.pyc/.pyo
> >files in packages)
At 10:25 PM 10/6/2008 +0100, Floris Bruynooghe wrote:
On Fri, Oct 03, 2008 at 12:35:11PM -0400, Phillip J. Eby wrote:
> I'm thinking about putting together a pre-PEP for a "Build Utilities,
> Installation Locations, & Distribution Standards" (BUILDS)
> specification.
Hehe, clever name!
> The ba
On Fri, Oct 03, 2008 at 12:35:11PM -0400, Phillip J. Eby wrote:
> I'm thinking about putting together a pre-PEP for a "Build Utilities,
> Installation Locations, & Distribution Standards" (BUILDS)
> specification.
Hehe, clever name!
> The basic idea for the first PEP is to:
[...]
> 2. Comment
At 07:00 PM 10/3/2008 +0200, Tarek Ziade wrote:
Phillip,
You said it was too early, 2 days ago when I sent a similar (less
detailed) mail where I expressed the need to start writing things
down in Python Wiki .
I understood you to be specifying implementation designs, not
creating a charter
Phillip,
You said it was too early, 2 days ago when I sent a similar (less detailed)
mail where I expressed the need to start writing things down in Python Wiki
.
But this work has already started, by Thoshio, me, and some others. mail.
http://wiki.python.org/moin/Distribute/Functionality for in
I'm thinking about putting together a pre-PEP for a "Build Utilities,
Installation Locations, & Distribution Standards" (BUILDS)
specification. But first, I want to throw out a few ideas to test
the waters, and to give a general idea of what the first PEP would cover.
The basic idea for the f
29 matches
Mail list logo
