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: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 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
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
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 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 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
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 TurboGears people are considering switching
from setupt
On Wed, Mar 25, 2009 at 7: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
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, now that buildout and pip
> seem
> to become popular. For
Tarek Ziadé gmail.com> writes:
>
> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
I am working on a TurboGears2-based app and I just did a count of the .egg
packages in the virtualenv. There are 45
On Wed, Mar 25, 2009 at 2:45 PM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> But I agree that the sizes of the packages are too small now, and it has gone
>> to far. Installing a web app like Plone is scary (+100 packages)
>
> I am working on a TurboGears2-based app and I just di
2009/3/25 Tarek Ziadé :
> I can't hear that setuptools has divided the Python community. It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python
> imho.
It's quite possi
On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote:
>
> Hence my comment about "dividing the community". From my limited
> perspective, it's about no longer having a standard Windows binary
> distribution format used by all, not about some sort of ideological
> battles. Sorry for being unclear.
Ar
At 12:25 PM 3/25/2009 +, 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
2009/3/25 Tarek Ziadé :
>> People should really stop splitting their work into micro-libraries (with
>> such
>> ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of
>> separately-packaged plugins (the repoze stuff). The Twisted approach is much
>> saner, where you have a coh
At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
Sometimes it also happens that, once one such build/packaging systems
is adopted, it is difficult to switch to using another one, since apps
(... and plugins systems ...) are frequently hard-coupled to the pkg
sys «exotic features» and support (...
2009/3/25 Tarek Ziadé :
> On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote:
>>
>> Hence my comment about "dividing the community". From my limited
>> perspective, it's about no longer having a standard Windows binary
>> distribution format used by all, not about some sort of ideological
>> battle
On Wed, Mar 25, 2009 at 7:31 AM, P.J. Eby wrote:
> Please note that entry points are not coupled to easy_install. They have a
> documented file format and API that's *distributed* with setuptools, but is
> not dependent on it and does not require .egg files, either. There's
> nothing stopping an
Paul Moore gmail.com> writes:
>
> Another division (Not one I'll try to blame on setuptools, though )
>
> Some people find larger, stable, unified packages more useful. Others
> find fine-grained, rapidly developing packages more useful.
>
> It sounds like Antoine and I fall into the former ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 9:02 AM, Tarek Ziadé wrote:
Yes but this means that you have to wait for the next version of the
"big" package
when a bug is corrected or a feature added, or you need to patch it.
(or maybe use the namespace trick to override it)
At 07:40 AM 3/25/2009 -0700, Guido van Rossum wrote:
Well, sorry, but this complex layered interdependent architecture is
one of the *causes* of confusion -- apart from you nobody knows what
is what exactly,
I'll pick a minor nit here... buildout, pip, and a wide variety of
other tools and fr
On Wed, Mar 25, 2009 at 9:31 AM, P.J. Eby wrote:
> At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> Sometimes it also happens that, once one such build/packaging systems
>> is adopted, it is difficult to switch to using another one, since apps
>> (... and plugins systems ...) are frequently h
On Wed, Mar 25, 2009 at 5:25 AM, Antoine Pitrou wrote:
>
> 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'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>> But I agree that the sizes of the packages are too small now, and it has gone
>> to far. Installing a web app like Plone is scary (+100 packages)
>
> I am working on a TurboGears2-based app an
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 is fine in a lot of
arena
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> Maybe there's a difference between being a Zope user and using zope
> packages? I think it's great that I can pick and choose
> zope.interfaces and other packages in my not-Zope project. But if I'm
> deploying actual Zope
At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
... but Trac plugins *do require* egg files ... (AFAIK after reading
Trac docs and implementation of plugin upload from /admin/plugins, egg
cache for plugins ... and so on ...) and this is what I was talking
about ... apps (e.g. Trac) depending *tod
On Thu, Mar 26, 2009 at 12:37 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>
>> Maybe there's a difference between being a Zope user and using zope
>> packages? I think it's great that I can pick and choose
>> zope.interfaces and other packages
On Wed, Mar 25, 2009 at 11:04 AM, P.J. Eby wrote:
> At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> ... but Trac plugins *do require* egg files ... (AFAIK after reading
>> Trac docs and implementation of plugin upload from /admin/plugins, egg
>> cache for plugins ... and so on ...) and this
On Wed, 25 Mar 2009 11:34:43 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
But I agree that the sizes of the packages are too small now, and it has gone
to far. Installing a web app like Plone is scary (+100 packa
Paul Moore wrote:
2009/3/25 Tarek Ziadé :
Since setuptools came on the scene, I can state with some certainty
that many packages which would otherwise have been distributed as
bdist_wininst installers, now aren't. In some cases, only source
packages are provided (on the basis that easy_install
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
But I agree that the sizes of the packages are too small now, and it has gone
to far. Installing a web app like Plone is scary (+100 packages)
I am working on a TurboGears2-based app and I just did a count of the .egg
packages in the virtua
Is setuptools/distutils/whatever on the agenda for the tomorrow's language
summit? Or is there some other get-together at PyCon for this?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Yes it's on the agenda
On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote:
Is setuptools/distutils/whatever on the agenda for the tomorrow's
language
summit? Or is there some other get-together at PyCon for this?
Skip
___
Python-Dev mailing list
P
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote:
> I use Python for systems admin scripts, Windows services, and database
> management. In my experience (and I agree, it's only one, limited, use
> case) availability of download-and-run bdist_wininst installers for
> every package I used was the
GSOC?
On Thu, Mar 26, 2009 at 6:05 AM, Steven Bethard wrote:
> On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote:
> > I use Python for systems admin scripts, Windows services, and database
> > management. In my experience (and I agree, it's only one, limited, use
> > case) availability of downlo
Yes,
I'll try to blog today the initial list of topics that will be
discussed during the Summit,
Regards
Tarek
2009/3/25 Jesse Noller :
> Yes it's on the agenda
>
> On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote:
>
>> Is setuptools/distutils/whatever on the agenda for the tomorrow's language
Paul Moore writes:
> If you would, I'd appreciate it. Sometimes I feel that the
> distutils/setuptools discussions need better input from the
> non-web-developer community. And even more so from the "not a
> developer, just a user" community!
And the often-obscured community: those who desperate
2009/3/25 Terry Reedy :
> Is it possible to write an egg to bdist converter (or vice versa)?
No idea. But would it help? Distributors would still only provide one
or the other, so when only an egg is available, I'd still have to
convert it - which is certainly pretty simple, but so is python
setup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:16 AM, David Cournapeau wrote:
It fails for software I am directly involved in, or maybe the layer
just below: for example, there is no way for me to get a python 2.6 on
my distribution (Ubuntu), so I cannot easily test the py
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 additional functionality into the
system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote:
Yes you're right, Trac requires .egg files for local plugins installs
(... in /plugins folder ;) so that not all environments but only one
be able to use the plugin ... but that's not exactly what I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:37 AM, Jean-Paul Calderone wrote:
If anything, Twisted's example shows how monolithic packages are
easier
all-around than micro-packages. We basically have the release
infrastructure
to release Twisted in many smaller piec
At 01:29 PM 3/25/2009 -0400, Terry Reedy wrote:
Paul Moore wrote:
2009/3/25 Tarek Ziadé :
Since setuptools came on the scene, I can state with some certainty
that many packages which would otherwise have been distributed as
bdist_wininst installers, now aren't. In some cases, only source
pack
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote:
I've found setuptools entry points difficult to work with for plugins,
I'd be interested in hearing more about your specific difficulties,
although it's probably off-topic for Python-Dev. Perhaps via the
distutils-sig, since we don't have a pl
At 11:35 AM 3/25/2009 -0500, Olemis Lang wrote:
Yes you're right, Trac requires .egg files for local plugins installs
(... in /plugins folder ;) so that not all environments but only one
be able to use the plugin ... but that's not exactly what I'm saying,
since setuptools AFAIK *MUST* be already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
In fact, I think it /has/ to.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 6:24 PM, P.J. Eby wrote:
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote:
I've found setuptools entry points difficult to work with for
plugins,
I'd be interested in hearing more about your specific difficulties,
although i
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 a different
opinion about insta
Ben Finney writes:
> And the often-obscured community: those who desperately want the
> Python stuff to just behave the same way everything else on their
> system does, i.e. be managed approrpiately by the operating system
> package manager. A Python-specific packaging system which makes it
> har
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!
Maybe next year
___
Python-Dev mailing list
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
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
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
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
>> 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
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
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 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
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 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
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:42 PM, Stephen J. Turnbull wrote:
>
> +-> E --> downstream developer -+
> | |
> | +--+ V
> source -> build -> A -> B -+-> C ->
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)
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 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
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
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 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
-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
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
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
-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
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.
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: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: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: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: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 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:
{{{
[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
-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
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
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,
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
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 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)
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
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
-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
-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
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
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
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
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
-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
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
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
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
1 - 100 of 146 matches
Mail list logo
