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
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.
On Fri, Mar 27, 2009 at 4:27 PM, Barry Warsaw ba...@python.org 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
make
Antoine Pitrou writes:
Lennart Regebro regebro at 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)
2009/3/25 Antoine Pitrou solip...@pitrou.net:
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
Lennart Regebro regebro at 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.
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 to drop
2009/3/27 Guido van Rossum gu...@python.org:
- 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
Paul Moore p.f.mo...@gmail.com 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
On Fri, Mar 27, 2009 at 8:28 PM, Ben Finney
bignose+hates-s...@benfinney.id.au 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
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
If some
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 this
On Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw ba...@python.org wrote:
On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org wrote:
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the ability
On Thu, Mar 26, 2009 at 6:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/26 Barry Warsaw ba...@python.org:
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.
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com 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
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
On Fri, Mar 27, 2009 at 7:49 AM, M.-A. Lemburg m...@egenix.com 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
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Guido van Rossum gu...@python.org:
- 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
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Guido van Rossum gu...@python.org:
- 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
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
Steve Careful, Glyph. Nobody likes a smart-ass ;-)
I think he'll be ok. He escaped the language summit with only minor wounds
yesterday. wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On 2009-03-27 13:58, David Cournapeau wrote:
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com 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
2009/3/27 David Cournapeau courn...@gmail.com:
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.
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 functionality in
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,
Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark
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
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 distributions,
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
On Fri, Mar 27, 2009 at 1:21 PM, Eric Smith e...@trueblade.com 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 also help.
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 the email
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
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
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
On Fri, Mar 27, 2009 at 2:27 PM, Eric Smith e...@trueblade.com 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 8:02 AM, Eric Smith e...@trueblade.com 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
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
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 under
On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake fdr...@acm.org 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.
On 2009-03-27 20:56, Guido van Rossum wrote:
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith e...@trueblade.com 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
On Fri, Mar 27, 2009 at 3:48 PM, M.-A. Lemburg m...@egenix.com 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
-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()
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 may
-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
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
-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
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 multiple
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 to
On Thu, Mar 26, 2009 at 2:42 PM, Stephen J. Turnbull step...@xemacs.org wrote:
+- E -- downstream developer -+
| |
| +--+ V
source - build - A - B
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 tleeuwenb...@gmail.com:
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:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com 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
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Depending on the definition of a resource there's additional
information that could be needed. For instance, if resource includes
message
-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 ba...@python.org wrote:
On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Depending on the definition of a resource there's additional
information that could be needed. For instance, if resource
-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
-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
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw ba...@python.org 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
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw ba...@python.org 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
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com 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
-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.
On Thu, Mar 26, 2009 at 2:47 PM, Olemis Lang ole...@gmail.com wrote:
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com 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
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou solip...@pitrou.net wrote:
Paul Moore p.f.moore at gmail.com writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a
-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
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com 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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com 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
-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, someone
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org 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
2009/3/26 Barry Warsaw ba...@python.org:
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
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw ba...@python.org:
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
-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 ba...@python.org
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be
-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 ba...@python.org
wrote:
BTW, under a better name, I would support putting pkg_resources in
the
stdlib.
... or a subset of it ? or integrating its
2009/3/26 Barry Warsaw ba...@python.org:
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
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 as
On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby p...@telecommunity.com 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
On Thu, Mar 26, 2009 at 4:33 PM, P.J. Eby p...@telecommunity.com wrote:
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw ba...@python.org:
BTW, under a better name, I would support putting pkg_resources in the
stdlib.
Last time I looked it was an incredibly
-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
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
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
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
complexity
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
Paul Moore p.f.moore at 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
On Wed, Mar 25, 2009 at 7:25 AM, Antoine Pitrou solip...@pitrou.net wrote:
Paul Moore p.f.moore at 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
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou solip...@pitrou.net wrote:
Paul Moore p.f.moore at 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
Tarek Ziadé ziade.tarek at 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.
On Wed, Mar 25, 2009 at 2:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
Tarek Ziadé ziade.tarek at 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
2009/3/25 Tarek Ziadé ziade.ta...@gmail.com:
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.
On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore p.f.mo...@gmail.com 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
At 12:25 PM 3/25/2009 +, Antoine Pitrou wrote:
Paul Moore p.f.moore at 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
2009/3/25 Tarek Ziadé ziade.ta...@gmail.com:
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
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é ziade.ta...@gmail.com:
On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore p.f.mo...@gmail.com 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
On Wed, Mar 25, 2009 at 7:31 AM, P.J. Eby p...@telecommunity.com 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
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou solip...@pitrou.net wrote:
Paul Moore p.f.moore at gmail.com writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a
Paul Moore p.f.moore at 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
-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
On Wed, Mar 25, 2009 at 9:31 AM, P.J. Eby p...@telecommunity.com 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 ...)
1 - 100 of 136 matches
Mail list logo
