P.J. Eby wrote:
I didn't say there's *no* desire, however IIRC the only person who
*ever* asked on distutils-sig how to do a base package with setuptools
was the author of the ll.* packages.
I've asked before ;-)
Chris
--
Simplistix - Content Management, Zope Python Consulting
Martin v. Löwis wrote:
I, for one, have been trying to figure out how to do base namespace
packages for years...
You mean, without PEP 382?
That won't be possible, unless you can coordinate all addon packages.
Base packages are a feature solely of PEP 382.
Marc-Andre has achieved this, I
-On [20090501 20:59], Martin v. Löwis (mar...@v.loewis.de) wrote:
Right: if all portions install into the same directory, you can have
base packages already.
Speaking as a user of packages, this use case is one I hardly ever encounter
with the Python software/modules/packages I use. The only ones
Right: if all portions install into the same directory, you can have
base packages already.
Speaking as a user of packages, this use case is one I hardly ever encounter
with the Python software/modules/packages I use. The only ones that spring
to mind are the mx.* and ll.* packages. The
-On [20090509 13:40], Martin v. Löwis (mar...@v.loewis.de) wrote:
There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*,
themerubber.*,
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote:
They're also all pure namespace packages rather than base + addons,
which is what we've been discussing...
But from Martin's email I understood it more as being base packages. Unless
I misunderstood, of course.
If correct,
Jeroen Ruigrok van der Werven wrote:
-On [20090509 13:40], Martin v. Löwis (mar...@v.loewis.de) wrote:
There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*,
Jeroen Ruigrok van der Werven wrote:
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote:
They're also all pure namespace packages rather than base + addons,
which is what we've been discussing...
But from Martin's email I understood it more as being base packages. Unless
I
P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and ll.*,
although I'd guess from the PyPI listings that perhaps Django is. (It
seems that base packages are more likely to use a 'base-extension'
naming pattern, vs. the 'namespace.project' pattern used by pure
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern, vs. the 'namespace.project' pattern
used by pure packages.)
At 05:35 PM 5/1/2009 +0100, Chris Withers wrote:
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern,
At 07:41 PM 5/1/2009 +0200, Martin v. Löwis wrote:
It's unclear, however, who is using base packages besides mx.* and
ll.*, although I'd guess from the PyPI listings that perhaps Django
is. (It seems that base packages are more likely to use a
'base-extension' naming pattern, vs. the
Actually, if you are using only the distutils, you can do this by
listing only modules in the addon projects; this is how the ll.* tools
are doing it. That only works if the packages are all being installed
in the same directory, though, not as eggs.
Right: if all portions install into the
On 04:56 am, p...@telecommunity.com wrote:
At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote:
Just as a use-case: would the Java com.* namespace be an example of
a pure package with no base? i.e. lots of projects are in it, but
no project owns it?
Er, I suppose. I was thinking more of
At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote:
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
I think that there is some confusion here. A main package or
buildout that assembles a larger project from components is not the
same thing as having a base package for a namespace
On 16 Apr, 03:36 pm, p...@telecommunity.com wrote:
At 03:46 AM 4/16/2009 +, gl...@divmod.com wrote:
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
Twisted has its own system for namespace packages, and I'm not
really sure where we fall in this discussion. I haven't been able to
At 03:58 AM 4/17/2009 +, gl...@divmod.com wrote:
Just as a use-case: would the Java com.* namespace be an example
of a pure package with no base? i.e. lots of projects are in it,
but no project owns it?
Er, I suppose. I was thinking more of the various 'com.foo' and
'org.bar' packages
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
[much quote-trimming, the following is intended to just give the gist,
but the bits quoted below are not in directe response to each other]
On Wed, Apr 15, 2009, P.J. Eby wrote:
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
[...]
Again: the PEP is about creating a standard for namespace
On 2009-04-15 16:44, P.J. Eby wrote:
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that
lives in
site-packages into smaller distribution
At 09:10 AM 4/15/2009 -0700, Aahz wrote:
For the benefit of us bystanders, could you summarize your vote at this
point? Given the PEP's intended goals, if you do not oppose the PEP, are
there any changes you think should be made?
I'm +1 on Martin's original version of the PEP, subject to the
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples
On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base
package
installation which optional add-ons that live in the same logical
package namespace.
The PEP provides a way to solve this use case by giving both
developers
and
On 2009-04-15 19:59, P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I expect
you will find a fair number of others, as well.
...
In other words, the base package
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I expect
you will find a fair number of others, as
On Wed, Apr 15, 2009 at 9:22 PM, P.J. Eby p...@telecommunity.com wrote:
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being
On 2009-04-15 21:22, P.J. Eby wrote:
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I
expect
At 10:20 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
Whether base packages are useful or not is really a side aspect
of the PEP and my proposal.
It's not whether they're useful, it's whether they're required. Your
proposal *requires* base packages, and for people who intend to use
pure
M.-A. Lemburg writes:
Hmm, setuptools doesn't support the notion of base packages, ie.
packages that provide their own __init__.py module, so I fail
to see how your list or any other list of setuptools-depend
packages can be taken as indicator for anything related to
base packages.
At 09:59 AM 4/16/2009 +0900, Stephen J. Turnbull wrote:
I think that for this PEP it's more important to unify
the various use cases for namespace packages than it is to get rid of
the .pth files.
Actually, Martin's proposal *does* get rid of the .pth files in
site-packages, and replaces them
On 15 Apr, 09:11 pm, p...@telecommunity.com wrote:
I think that there is some confusion here. A main package or
buildout that assembles a larger project from components is not the
same thing as having a base package for a namespace package.
I'm certainly confused.
Twisted has its own
On 2009-04-07 19:46, P.J. Eby wrote:
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another separate hierarchy
of special files which
On 2009-04-14 18:27, P.J. Eby wrote:
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this works is by having a base distribution
[Resent due to a python.org mail server problem]
On 2009-04-03 22:07, Martin v. Löwis wrote:
I'd like to extend the proposal to Python 2.7 and later.
I don't object, but I also don't want to propose this, so
I added it to the discussion.
My (and perhaps other people's) concern is that 2.7
On 2009-04-03 02:44, P.J. Eby wrote:
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
Alternative Approach:
-
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1) check ?
One of the namespace
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1) check ?
Again - this wouldn't be O(1). More importantly, it breaks system
packages, which now again have to deal
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1)
check ?
Again - this wouldn't be O(1). More importantly, it breaks
On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg m...@egenix.com wrote:
This means your proposal actually doesn't add any benefit over the
status quo, where you can have an __init__.py that does nothing but
declare the package a namespace. We already have that now, and it
doesn't need a new
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1)
check ?
Again - this
Martin v. Löwis wrote:
Chris Withers wrote:
Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
-1 to adding it to the 2.x series.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this
At 02:00 PM 4/6/2009 +0100, Chris Withers wrote:
Martin v. Löwis wrote:
Chris Withers wrote:
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large optional chunks separately, but
P.J. Eby wrote:
See the third paragraph of
http://www.python.org/dev/peps/pep-0382/#discussion
Indeed, I guess the PEP could be made more explanatory then 'cos, as a
packager, I don't see what I'd put in the various setup.py and
__init__.py to make this work...
That said, I'm delighted to
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose
On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On
On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Mon, Apr 6, 2009 at 12:28 PM, R. David Murray rdmur...@bitdance.com
wrote:
On Mon, 6 Apr 2009 at 12:00, Jesse Noller wrote:
On Mon, Apr 6, 2009 at 9:26 AM, Barry Warsaw ba...@python.org wrote:
-BEGIN PGP SIGNED
Perhaps we could add something like a sys.namespace_packages that would
be updated by this mechanism? Then, pkg_resources could check both that
and its internal registry to be both backward and forward compatible.
I could see no problem with that, so I have added this to the PEP.
Thanks for
Chris Withers wrote:
Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Would this support the following case:
I have a package called mortar, which defines useful stuff:
from mortar import content, ...
I now want to distribute large
On 08:15 pm, mar...@v.loewis.de wrote:
Note that there is no such thing as a defining namespace package --
namespace package contents are symmetrical peers.
With the PEP, a defining package becomes possible - at most one
portion can define an __init__.py.
For what it's worth, this is a
At 10:15 PM 4/3/2009 +0200, Martin v. Löwis wrote:
I should make it clear that this is not the case. I envision it to work
this way: import zope
- searches sys.path, until finding either a directory zope, or a file
zope.{py,pyc,pyd,...}
- if it is a directory, it checks for .pkg files. If it
On Fri, Apr 3, 2009 at 13:15, Martin v. Löwis mar...@v.loewis.de wrote:
Note that there is no such thing as a defining namespace package --
namespace package contents are symmetrical peers.
With the PEP, a defining package becomes possible - at most one
portion can define an __init__.py.
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm to compute the packages __path__ must
At 10:32 AM 4/2/2009 -0500, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
An excellent idea. One thing I am not 100% clear on, is how to get
additions to sys.path to work correctly with this. Currently, when
pkg_resources adds a new egg to
P.J. Eby wrote:
Apart from that, this mechanism sounds great! I only wish there was a
way to backport it all the way to 2.3 so I could drop the messy bits
from setuptools.
Maybe we could? :-)
Chris
--
Simplistix - Content Management, Zope Python Consulting
-
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
Please comment.
Regards,
Martin
Specification
=
Rather than using an imperative
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
That's going to slow down Python package detection a lot - you'd
replace an O(1) test with an O(n) scan.
I thought about this too, but it's pretty trivial considering that
the only time it takes effect is when you have a directory name that
Martin v. Löwis schrieb:
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm
At 03:21 AM 4/3/2009 +0200, Matthias Klose wrote:
+1 speaking as a downstream packaging python for Debian/Ubuntu I
welcome this approach. The current practice of shipping the very
same file (__init__.py) in different packages leads to conflicts for
the installation of these packages (this is
66 matches
Mail list logo
