On Fri, Mar 27, 2009 at 4:27 PM, Barry Warsaw wrote:
> On Mar 27, 2009, at 2:27 PM, Eric Smith wrote:
>> Olemis Lang wrote:
I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not
to
mak
Tres Seaver a écrit :
Note that the kind of applications I work on tend to be the sort which
will run as server apps, and which will (in production) be the entire
rasion d'etre for the machine they run on, which makes the cost of
isolation tiny compared to the consequences of failed isolation.
Tennessee Leeuwenburg a écrit :
I would suggest there may be three use cases for Python installation
tools. Bonus -- I'm not a web developer! :)
Case One: Developer wishing to install additional functionality into the
system Python interpreter forever
Case Two: Developer wishing to install add
Antoine Pitrou writes:
> Lennart Regebro gmail.com> writes:
> >
> > The people who use pythonlibraries are programmers. It can be expected
> > that they are comfortable with the command line.
>
> You probably haven't met lots of Windows (so-called) programmers...
Hey, the "(so-called)" sh
Lennart Regebro gmail.com> writes:
>
> The people who use pythonlibraries are programmers. It can be expected
> that they are comfortable with the command line.
You probably haven't met lots of Windows (so-called) programmers...
Regards
Antoine.
__
2009/3/25 Antoine Pitrou :
> I'm not a Windows user, but I suppose it boils down to whether people are
> comfortable with the command-line or not (which even many Windows /developers/
> aren't). Since having GUIs for everything is part of the Windows philosophy,
> it's a fair expectation that Pytho
On Mar 27, 2009, at 6:22 PM, P.J. Eby wrote:
At 10:22 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called "FryingPan" to
create "Omelettes", ie. all eggs squashed into a single ZIP
file... ;-)
They're called baskets actually. ;-) There's no tool
At 10:22 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called "FryingPan" to
create "Omelettes", ie. all eggs squashed into a single ZIP file... ;-)
They're called baskets actually. ;-) There's no tool to do it, but
pkg_resources does support multipl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
s...@pobox.com wrote:
> mal> Zip files are great for shipping packages to the end-user, but
> mal> there's no need to keep them zipped once they get there.
>
> I thought one of the arguments for zip files was a performance increase
> (reduced
On Mar 27, 2009, at 5:22 PM, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called "FryingPan" to
create "Omelettes", ie. all eggs squashed into a single ZIP
file... ;-)
I've certainly suggested such a tool in various conversations, but it
usually comes down to not wan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 27, 2009, at 2:27 PM, Eric Smith wrote:
Olemis Lang wrote:
I also think the feature should go. If you want functionality
that's so
difficult to provide when you install as a zip file, the answer is
not to
make things more complex, but to
On 2009-03-27 20:24, s...@pobox.com wrote:
> mal> Zip files are great for shipping packages to the end-user, but
> mal> there's no need to keep them zipped once they get there.
>
> I thought one of the arguments for zip files was a performance increase
> (reduced stat(2) calls, etc). I ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 27, 2009, at 7:51 AM, Olemis Lang wrote:
from pkg_resources import *
for fnm in sorted(resource_listdir('mailman.database', 'sql'), \
my_own_cmp ): # Only if needed ... ;)
Thanks, it was pkg_resource.resource_listdir() th
On Fri, Mar 27, 2009 at 3:48 PM, M.-A. Lemburg wrote:
> More importantly:
>
> Why is the non-use of a command by a single Python developer enough
> motivation to remove a useful feature of distutils that's been in
> use by many others for years ?
>From the discussions I had with RPM packagers, bd
On 2009-03-27 20:56, Guido van Rossum wrote:
> On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith wrote:
>> M.-A. Lemburg wrote:
>>> On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to
On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake wrote:
> On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote:
>>
>> One of the motivations for deprecating this (and for using this
>> specific example) was that Matthias Klose, the Python packager for
>> Debian, said he never uses bdist_rpm.
>
> Given t
At 08:12 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
On 2009-03-27 17:19, P.J. Eby wrote:
> At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
>> (*) I've had a go at this a few months ago and then found out
>> that the egg format itself is not documented anywhere.
>
> It's been documented for just u
On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote:
One of the motivations for deprecating this (and for using this
specific example) was that Matthias Klose, the Python packager for
Debian, said he never uses bdist_rpm.
Given that Debian doesn't use RPMs, isn't that expected?
I'm actually in
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith wrote:
> M.-A. Lemburg wrote:
>>
>> On 2009-03-27 04:19, Guido van Rossum wrote:
>>>
>>> - keep distutils, but start deprecating certain higher-level
>>> functionality in it (e.g. bdist_rpm)
>>> - don't try to provide higher-level functionality in the st
On Fri, Mar 27, 2009 at 2:27 PM, Eric Smith wrote:
> Olemis Lang wrote:
>>>
>>> I also think the feature should go. If you want functionality that's so
>>> difficult to provide when you install as a zip file, the answer is not to
>>> make things more complex, but to not install as zip files.
>>>
>
On Mar 27, 2009, at 3:24 PM, s...@pobox.com wrote:
I thought one of the arguments for zip files was a performance
increase
(reduced stat(2) calls, etc). I may misremember though.
You're memory is working fine, but I don't think the way eggs are used
accomplishes that.
The measurements t
Olemis Lang wrote:
I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not to
make things more complex, but to not install as zip files.
What about environments like Google App Engine ? I mean, AFAIK using
Z
mal> Zip files are great for shipping packages to the end-user, but
mal> there's no need to keep them zipped once they get there.
I thought one of the arguments for zip files was a performance increase
(reduced stat(2) calls, etc). I may misremember though.
Skip
On 2009-03-27 17:19, P.J. Eby wrote:
> At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
>> (*) I've had a go at this a few months ago and then found out
>> that the egg format itself is not documented anywhere.
>
> It's been documented for just under three years now. Here's where you
> quoted th
On Fri, Mar 27, 2009 at 1:21 PM, Eric Smith wrote:
> M.-A. Lemburg wrote:
>> On 2009-03-27 17:07, P.J. Eby wrote:
>>> At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
>
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would a
M.-A. Lemburg wrote:
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distri
On 2009-03-27 17:07, P.J. Eby wrote:
> At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
>> P.J. Eby wrote:
>> > As someone else suggested, moving some of the functionality to PEP 302
>> > interfaces would also help. Most of the code, though, deals with
>> > locating/inspecting installed distribution
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would also help. Most of the code, though, deals with
> locating/inspecting installed distributions, resolving version
> requirements, and managing
Guido van Rossum wrote:
> 2009/3/26 Toshio Kuratomi :
>> Guido van Rossum wrote:
>>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark them as being
speci
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where
you quoted the email where I announced that documentation, p
On 2009-03-27 15:00, Ronald Oussoren wrote:
>
> On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
>
>> On 2009-03-27 04:19, Guido van Rossum wrote:
>>> - keep distutils, but start deprecating certain higher-level
>>> functionality in it (e.g. bdist_rpm)
>>> - don't try to provide higher-level functi
2009/3/27 David Cournapeau :
> Concerning contribution for windows binaries: as the current numpy
> developer in charge of windows binaries and windows support for a
> while, my experience is that the windows situation for contribution is
> very different from the other platforms. The mentality is
On 2009-03-27 13:58, David Cournapeau wrote:
> On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg wrote:
>
>> I think that esp. the bdist_* commands help developers a lot by
>> removing the need to know how to build e.g. RPMs or Windows
>> installers and let distutils deal with it.
>
> I think it is
Steve> Careful, Glyph. Nobody likes a smart-ass ;-)
I think he'll be ok. He escaped the language summit with only minor wounds
yesterday.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore wrote:
2009/3/27 Guido van Rossum :
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tool
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore wrote:
> 2009/3/27 Guido van Rossum :
>> - keep distutils, but start deprecating certain higher-level
>> functionality in it (e.g. bdist_rpm)
>> - don't try to provide higher-level functionality in the stdlib, but
>> instead let third party tools built o
On Fri, Mar 27, 2009 at 7:49 AM, M.-A. Lemburg wrote:
> On 2009-03-27 04:19, Guido van Rossum wrote:
>> - keep distutils, but start deprecating certain higher-level
>> functionality in it (e.g. bdist_rpm)
>> - don't try to provide higher-level functionality in the stdlib, but
>> instead let third
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs c
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg wrote:
> I think that esp. the bdist_* commands help developers a lot by
> removing the need to know how to build e.g. RPMs or Windows
> installers and let distutils deal with it.
I think it is a big dangerous to build rpm/deb without knowing how to
On Thu, Mar 26, 2009 at 6:27 PM, Paul Moore wrote:
> 2009/3/26 Barry Warsaw :
>> Let me clarify my position: I just want the functionality (preferably in the
>> stdlib); I don't really care how it's spelled (except please not
>> pkg_resource.whatever() :).
>
> Agreed.
+1
--
Regards,
Olemis.
B
On Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw wrote:
> On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
>> On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw wrote:
>>> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>>>
>>> One thing that /would/ be helpful though is the ability to list all
>>
On 2009-03-27 04:19, Guido van Rossum wrote:
> - keep distutils, but start deprecating certain higher-level
> functionality in it (e.g. bdist_rpm)
> - don't try to provide higher-level functionality in the stdlib, but
> instead let third party tools built on top of these core APIs compete
Should t
Tarek Ziadé wrote:
> So if we, for once, forget about the central site-packages and define some
> kind of configuration process that is run when every script is launched
> to decide what packages should be loaded, we could seperate
> "python the interpreter" from "python the pile of packages"
>
>
On Fri, Mar 27, 2009 at 8:28 PM, Ben Finney
wrote:
>
> I would argue that the Python community has a wealth of people quite
> capable of taking on this particular task, and if it makes the core
> architecture and maintenance of ‘distutils’ simpler to remove special
> cases for binary installers,
Paul Moore writes:
> Please don't move bdist_wininst out of the core, though!
>
> I'd argue that Windows is a special case, as many Windows users
> don't have the ability to build their own extensions, so they rely
> heavily on binary installers. And there's no "Windows packagers"
> organisation
2009/3/27 Guido van Rossum :
> - keep distutils, but start deprecating certain higher-level
> functionality in it (e.g. bdist_rpm)
> - don't try to provide higher-level functionality in the stdlib, but
> instead let third party tools built on top of these core APIs compete
Please don't move bdist_
gl...@divmod.com wrote:
> On 26 Mar, 07:22 pm, ba...@python.org wrote:
>> One thing that /would/ be helpful though is the ability to list all
>> the resources under a specific package path. This is (I think) one
>> use case that pkg_resource fails to support and it's the one place
>> that I've had
On 26 Mar, 07:22 pm, ba...@python.org wrote:
One thing that /would/ be helpful though is the ability to list all
the resources under a specific package path. This is (I think) one
use case that pkg_resource fails to support and it's the one place
that I've had to drop down to file system intro
P.J. Eby wrote:
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would also help. Most of the code, though, deals with
> locating/inspecting installed distributions, resolving version
> requirements, and managing sys.path. And most of the nastiest
> complexit
Olemis Lang wrote:
... well ... it is too long ... :-§ ... perhaps it is better this way ...
--lmdtbicdfyeiwdimoweiiiapiyssiansey ... :P
Isn't that the name of a town in Wales somewhere?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
Guido van Rossum wrote:
Can I suggest that API this takes a glob-style pattern?
Globs would be nice to have, but the minimum
needed is some kind of listdir-like functionality.
Globbing can be built on that if need be.
--
Greg
___
Python-Dev mailing l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 10:07 PM, Guido van Rossum wrote:
If it really is a common habit to have single-file modules with
associated data files directly rooted under a namespace package, we
could change the API to allow passing in a module and have it b
On Thu, Mar 26, 2009 at 4:33 PM, P.J. Eby wrote:
> At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
>>
>> 2009/3/26 Barry Warsaw :
>> > BTW, under a better name, I would support putting pkg_resources in the
>> > stdlib.
>>
>> Last time I looked it was an incredibly complicated piece of code th
On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby wrote:
> At 11:27 PM 3/26/2009 +, Paul Moore wrote:
>>
>> What I'd really like is essentially some form of "virtual filesystem"
>> access to stuff addressed relative to a Python package name,
>
> Note that relative to a *Python package name* isn't quit
At 11:27 PM 3/26/2009 +, Paul Moore wrote:
What I'd really like is essentially some form of "virtual filesystem"
access to stuff addressed relative to a Python package name,
Note that relative to a *Python package name* isn't quite as useful,
due to namespace packages. To be unambiguous a
2009/3/26 Barry Warsaw :
> Let me clarify my position: I just want the functionality (preferably in the
> stdlib); I don't really care how it's spelled (except please not
> pkg_resource.whatever() :).
Agreed. My one major reservation is that conceptually, the whole
pkg_resource infrastructure seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 3:14 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:53 PM, Barry Warsaw
wrote:
BTW, under a better name, I would support putting pkg_resources in
the
stdlib.
... or a subset of it ? or integrating its features with PE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw :
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before it would be
main
2009/3/26 Barry Warsaw :
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before it would be
maintainable by the core developers. I never did manage to
On Thu, Mar 26, 2009 at 3:03 PM, wrote:
>
> Tres> Exactly: I never use easy_isntall to put packages into the system
> Tres> python. in fact, I only use it inside a virtalenv-generated
> Tres> isolated environment.
>
> While standing in line for lunch today, someone (don't know his name)
On Thu, Mar 26, 2009 at 2:53 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>
>> {{{
>
> [x for x in dir(pkg_resources) if all(y in x for y in ['dir',
> 'resource_'])]
>>
>> ['resource_isdir', 'resource_list
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>
> One thing that /would/ be helpful though is the ability to list all the
> resources under a specific package path. This is (I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
s...@pobox.com wrote:
> Tres> Exactly: I never use easy_isntall to put packages into the system
> Tres> python. in fact, I only use it inside a virtalenv-generated
> Tres> isolated environment.
>
> While standing in line for lunch today,
Tres> Exactly: I never use easy_isntall to put packages into the system
Tres> python. in fact, I only use it inside a virtalenv-generated
Tres> isolated environment.
While standing in line for lunch today, someone (don't know his name)
suggested that easy_install needs an --i-am-an-i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olemis Lang wrote:
> On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Barry Warsaw wrote:
>>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>>
For case one, where I want to
2009/3/26 Toshio Kuratomi :
> Guido van Rossum wrote:
>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>>> I think Distutils (and therefore Setuptools) should provide some APIs
>>> to play with special files (like resources) and to mark them as being
>>> special,
>>> no matter where they en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
{{{
[x for x in dir(pkg_resources) if all(y in x for y in ['dir',
'resource_'])]
['resource_isdir', 'resource_listdir']
BTW, under a better name, I would support putting pkg_resources in the
st
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>
>>> For case one, where I want to install additional functionality into my
>>> system Python interpreter "fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the ability to list
all the
resources under a specific package path. This is (I think) one
use case
that pkg_resource fails to support and it's the one pl
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
>> Paul Moore gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse
On Thu, Mar 26, 2009 at 2:47 PM, Olemis Lang wrote:
> On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Barry Warsaw wrote:
>>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>>
For case one, where I want to install addi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:41 PM, Tarek Ziadé wrote:
I think shutil.copytree new ignore mechanism handles this use case
pretty well (see the ignore_patterns factory in
http://docs.python.org/library/shutil.html)
Maybe we could use the same pattern.
Th
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>
>>> For case one, where I want to install additional functionality into my
>>> system Python interpreter "fo
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
>
>>> One thing that /would/ be helpful though is the ability to list all the
>>> resources under a specific package path. This is (I thi
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
>
>>> One thing that /would/ be helpful though is the ability to list all the
>>> resources under a specific package path. This is (I thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>
>> For case one, where I want to install additional functionality into my
>> system Python interpreter "forever", it would be great to have my
>> system
>> manage this.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
One thing that /would/ be helpful though is the ability to list all
the
resources under a specific package path. This is (I think) one use
case
that pkg_resource fails to support and it's the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tennessee Leeuwenburg wrote:
> I would suggest there may be three use cases for Python installation tools.
> Bonus -- I'm not a web developer! :)
> Case One: Developer wishing to install additional functionality into the
> system Python interpreter for
On Thu, Mar 26, 2009 at 12:22 PM, Barry Warsaw wrote:
> On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
>> 2009/3/26 Toshio Kuratomi :
>>> Depending on the definition of a "resource" there's additional
>>> information that could be needed. For instance, if resource includes
>>> message catal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
> 5. Much of this discussion reminds me of the debates between lumping and
> splitting of taxonomic categories in biology. Like that debate, it will
> continue forever.
Funny, I was thinking the same thing, only with respect to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi :
Depending on the definition of a "resource" there's additional
information that could be needed. For instance, if resource includes
message catalogs, then being a
2009/3/26 Toshio Kuratomi :
> Guido van Rossum wrote:
>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>>> I think Distutils (and therefore Setuptools) should provide some APIs
>>> to play with special files (like resources) and to mark them as being
>>> special,
>>> no matter where they en
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>> I think Distutils (and therefore Setuptools) should provide some APIs
>> to play with special files (like resources) and to mark them as being
>> special,
>> no matter where they end up in the target system.
>>
>> So
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
> I think Distutils (and therefore Setuptools) should provide some APIs
> to play with special files (like resources) and to mark them as being special,
> no matter where they end up in the target system.
>
> So the code inside the package can us
2009/3/25 Tennessee Leeuwenburg :
> I would suggest there may be three use cases for Python installation tools.
> Bonus -- I'm not a web developer! :)
> Case One: Developer wishing to install additional functionality into the
> system Python interpreter forever
> Case Two: Developer wishing to inst
On Mar 25, 2009, at 11:02 PM, Nick Coghlan wrote:
That is, the full workflow that should really be happening is
something like the following:
Developer(s)
|
V
(distutils/setuptools/pip/zc.buildout/etc)
On Thu, Mar 26, 2009 at 2:42 PM, Stephen J. Turnbull wrote:
>
> +-> E --> downstream developer -+
> | |
> | +--+ V
> source -> build -> A -> B -+-> C ->
David Cournapeau writes:
> On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
>
> > If that perception is accurate, then any changes likely need to focus on
> > the *opposite* end of the toolchain: the part between the " > packaging spec>" and the end users.
>
> Yes - but is this part
On Thu, Mar 26, 2009 at 2:01 PM, Nick Coghlan wrote:
> Yes, that metadata is what I meant to refer to rather than zipped .egg
> files specifically. An egg is just one example of something which
> includes that metadata.
Ok, my bad. Being able to describe meta-data for installed files is
indeed s
Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote:
>> Why coming from eggs and not from the build tool provided by python
>> itself (distutils) ? I don't see what eggs brings - specially since
>> the format is not even standardized.
>
> I don't think the "egg as a forma
On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote:
> On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
>
>> If that perception is accurate, then any changes likely need to focus on
>> the *opposite* end of the toolchain: the part between the "> packaging spec>" and the end users.
>
> Ye
On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
> If that perception is accurate, then any changes likely need to focus on
> the *opposite* end of the toolchain: the part between the " packaging spec>" and the end users.
Yes - but is this part the job of python ?
> In other words: Given a
On Mar 25, 2009, at 5:25 AM, Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout
and pip seem
to become popular. For example, the Tu
>> http://bugs.python.org/setuptools/issue63
>>
>> I don't understand how that can possibly be manageable.
>>
Steve> Note that the issue contains a broken link.
Fixed. Looks like a Roundup bug.
Skip
___
Python-Dev mailing list
Py
Jeff Hall wrote:
> Someone asked for the input of "ordinary users" (i.e. non developers)
> which, unfortunately, most of the people on this list don't fall in. My
> experience with setuptools is that it's poorly documented and assumes a
> level of sophistication that isn't always there. While this
s...@pobox.com wrote:
> Barry> In fact, I think it /has/ to. I'll go further and say that I'm
> Barry> very wary of using easy_install and the like to install
> Barry> non-distro provided packages into the system Python.
>
> Give that man a ceegar. The pyjamas author seems to have
On Thu, Mar 26, 2009 at 3:29 AM, Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull
> wrote:
>> Tennessee Leeuwenburg writes:
>> > GSOC?
>>
>> No. This is territory that nobody knows how to mentor yet, ya know?
>> Try it now, and the poor student is likely to find him or
On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull wrote:
> Tennessee Leeuwenburg writes:
> > GSOC?
>
> No. This is territory that nobody knows how to mentor yet, ya know?
> Try it now, and the poor student is likely to find him or herself at
> the center of a firestorm!
No, we wil
>
> Maybe
1 - 100 of 146 matches
Mail list logo
