I am running into something very odd on an Ubuntu 11.10 system: it looks
like namespace packages are entirely broken there. Here is a pdb session
to demonstrate:
(Pdb) import repoze
(Pdb) repoze
module 'repoze' from
See the posts from Felix Schwarz here a few days ago. It looks like
he ran into and
debugged the same issue. I haven't had a chance to wade into it. (I can't
say I'm looking forward to it.)
I'll try to get up to speed on this this weekend.
Jim
On Thu, Apr 12, 2012 at 6:16 AM, Wichert Akkerman
On Thu, Apr 12, 2012 at 12:16:22PM +0200, Wichert Akkerman wrote:
I am running into something very odd on an Ubuntu 11.10 system: it
looks like namespace packages are entirely broken there.
Interesting. As a data point: I use zc.buildout 1.5.2 on Ubuntu 11.10.
I haven't encountered any
On Apr 12, 2012, at 05:51 PM, Marius Gedminas wrote:
Interesting. As a data point: I use zc.buildout 1.5.2 on Ubuntu 11.10.
I haven't encountered any namespace issues yet.
I haven't seen any issues with zc.buildout 1.5.2 on Ubuntu 12.04 either.
Cheers,
-Barry
signature.asc
Description: PGP
Hey,
Am 12.04.2012 15:38, schrieb Jim Fulton:
See the posts from Felix Schwarz here a few days ago. It looks like
he ran into and debugged the same issue. I haven't had a chance to wade into
it. (I can't
say I'm looking forward to it.)
I think my last two emails contain a detailed
Let me try to answer some questions that came up:
- the buildout I used to reproduce this is this one:
https://github.com/euphorie/Euphorie
- this was using buildout 1.5.2
On 2012-4-12 12:16, Wichert Akkerman wrote:
I am running into something very odd on an Ubuntu 11.10 system: it looks
Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy, and the current plan requires putting some
source code into actual module distributions at the level of some of
the namespace packages.
Am 14.12.2010 00:11, schrieb Brad Allen:
Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy, and the current plan requires putting some
source code into actual module distributions at the
On Mon, Dec 13, 2010 at 5:57 PM, Martin v. Löwis mar...@v.loewis.de wrote:
You can't put code into __init__.py of any of the namespace packages.
Otherwise, having additional modules in any of these packages is fine.
Ok, that answers my question. Thanks!
At 05:11 PM 12/13/2010 -0600, Brad Allen wrote:
Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy,
Note that you don't *need* to use namespace paths to reflect
dependencies; the main purpose
On Sun, Apr 25, 2010 at 03:34, P.J. Eby p...@telecommunity.com wrote:
One thing that's not entirely clear at the moment in PEP 382, though, is
that it doesn't really specify how the other sys.path entries are found and
mapped -- presumably it's something like os.path.join(syspathentry,
On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is not even the issue of many eggs (I always install
things with --single-version-externally-managed and I forbid any code
to write into
On Fri, Apr 23, 2010 at 9:23 AM, David Cournapeau courn...@gmail.com wrote:
On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is not even the issue of many eggs (I always install
things with
On Fri, Apr 23, 2010 at 4:51 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Fri, Apr 23, 2010 at 9:23 AM, David Cournapeau courn...@gmail.com wrote:
On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is
On Fri, Apr 23, 2010 at 10:30 AM, David Cournapeau courn...@gmail.com wrote:
[..]
This all sounds complicated. pkg_resources is already complicated
enough (the other big reason why I don't use it in any of my
packages). Without a clear specification of what pkg_resources or its
successor is
On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I am not sure what you are defining as complicated. While pkg_resources
is hard to read and it's a project on its own with many other
features, the use case
we are talking about here is dead simple:
scan all sys.path
On Fri, Apr 23, 2010 at 12:01 PM, David Cournapeau courn...@gmail.com wrote:
On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I am not sure what you are defining as complicated. While pkg_resources
is hard to read and it's a project on its own with many other
On Fri, Apr 23, 2010 at 7:16 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
But guessing is not the right thing to do for optimization, we need facts.
So if you come back with some profiling information on your use case
where it seems so slow
Here is what cProfile -s cum gives me for a script
On Fri, Apr 23, 2010 at 1:38 PM, David Cournapeau courn...@gmail.com wrote:
On Fri, Apr 23, 2010 at 7:16 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
But guessing is not the right thing to do for optimization, we need facts.
So if you come back with some profiling information on your use case
At 04:23 PM 4/23/2010 +0900, David Cournapeau wrote:
Importing pkg_resources
causes many more syscalls than relatively big packages (~ 1000 for
python -c , 3000 for importing one of numpy/wx/gtk, 6000 for
pkg_resources). Assuming those are unavoidable (and the current
namespace implementation
At 12:16 PM 4/23/2010 +0200, Tarek Ziadé wrote:
On Fri, Apr 23, 2010 at 12:01 PM, David Cournapeau courn...@gmail.com wrote:
On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I am not sure what you are defining as complicated. While pkg_resources
is hard to read and
On Sat, Apr 24, 2010 at 1:32 AM, P.J. Eby p...@telecommunity.com wrote:
If you don't mind trying a simple test for me, would you patch your
pkg_resources to comment out this loop:
for pkg in self._get_metadata('namespace_packages.txt'):
if pkg in sys.modules:
On Sat, Apr 24, 2010 at 1:43 AM, P.J. Eby p...@telecommunity.com wrote:
At 08:38 PM 4/23/2010 +0900, David Cournapeau wrote:
275 0.024 0.000 0.151 0.001 posixpath.py:351(realpath)
Ouch. So, over one third of the execution time is spent translating
symlinks? That seems...
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in common,
If that were actually true (it isn't), then it
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in common,
If that were actually true (it isn't), then it
At 04:36 PM 4/22/2010 +0900, David Cournapeau wrote:
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in
At 04:49 PM 4/22/2010 +0900, David Cournapeau wrote:
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in
On Fri, Apr 23, 2010 at 1:10 AM, P.J. Eby p...@telecommunity.com wrote:
At 04:36 PM 4/22/2010 +0900, David Cournapeau wrote:
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby p...@telecommunity.com wrote:
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools
At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is not even the issue of many eggs (I always install
things with --single-version-externally-managed and I forbid any code
to write into easy_install.pth). Importing pkg_resources alone
(python -c import pkg_resources) takes
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it efficient to use?
* any reason why one should not use it?
Thanks Manlio
___
On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
manlio_peri...@libero.it wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it efficient to use?
* any reason why one should
On Apr 21, 2010, at 05:37 PM, Baiju M wrote:
On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
manlio_peri...@libero.it wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it
On Wed, Apr 21, 2010 at 2:14 PM, Barry Warsaw ba...@python.org wrote:
On Apr 21, 2010, at 05:37 PM, Baiju M wrote:
On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
manlio_peri...@libero.it wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
Manlio Perillo wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it efficient to use?
I have heard that it is slow if you're operating on NFS, as it causes
lots more
Last time we've mentioned this pep on Python-dev, Martin said he would
do its implementation.
Therefore, I am not sure what's the state on his side,.. cc'ing him
Unfortunately, I haven't made any progress - I still *plan* to do it
before the 3.2 betas, though. Contributions are welcome, of
On Apr 21, 2010, at 08:45 PM, Martin v. Löwis wrote:
Last time we've mentioned this pep on Python-dev, Martin said he would
do its implementation.
Therefore, I am not sure what's the state on his side,.. cc'ing him
Unfortunately, I haven't made any progress - I still *plan* to do it
before
On Mon, Apr 19, 2010 at 20:37, Manlio Perillo manlio_peri...@libero.it wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
All of Zope and Plone uses it all the time. Trust us, it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro ha scritto:
On Mon, Apr 19, 2010 at 20:37, Manlio Perillo manlio_peri...@libero.it
wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for
At 09:26 PM 4/21/2010 +0200, Manlio Perillo wrote:
But I do not want to use a feature that it is here for compatiblity
only, in a new project.
Python itself has supported namespace packages through a stdlib
utility since Python 2.3, and special import mechanism support has
been proposed for
On Tue, Apr 20, 2010 at 3:37 AM, Manlio Perillo
manlio_peri...@libero.it wrote:
* will this feature be supported for future setup tools?
* is it efficient to use?
It is slower than conventional packages import. I still don't
understand the whole implementation well, but I think there is an
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in common,
If that were actually true (it isn't), then it would be considered a
bug in setuptools.
When you build a package for
Hi All,
I want to be able to do things such as:
from mortar import content
from mortar.sqlalchemy import storage
...but where mortar is distrubuted as one package and mortar.sqlalchemy
(and a whole lot more like it...) are distributed as seperate packages.
Is this possible?
cheers,
Chris
On 2008-11-21 09:49, Chris Withers wrote:
Hi All,
I want to be able to do things such as:
from mortar import content
from mortar.sqlalchemy import storage
...but where mortar is distrubuted as one package and mortar.sqlalchemy
(and a whole lot more like it...) are distributed as
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in all
the others?
No, apparently the manual import doesn't help. Presumably the ones
you changed need something more
Ryan May wrote:
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in all
the others?
No, apparently the manual import doesn't help. Presumably the ones
you changed need
On Thu, August 9, 2007 4:02 pm, Ryan May wrote:
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in
all
the others?
No, apparently the manual import doesn't help.
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in all
the others?
No, apparently the manual import doesn't help. Presumably the ones
you changed need something more like this:
import enthought; enthought.traits =
It worked. Problem solved.
Thanks.
Stan Klein
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in all
the others?
No, apparently the manual import doesn't help.
At 04:42 PM 7/25/2007 -0400, Stanley A. Klein wrote:
I've been trying to build rpms of enthought system components. Some of
them use namespace packages. Those packages have the required __init__.py
files containing
__import__('pkg_resources').declare_namespace(__name__).
According to the
49 matches
Mail list logo
