Importing Cython .so module
Emil
sage: from foo.all import *
Now, foo.all imports several things from the "foo" directory,
including a .so module. It contains lines like:
from buzz import *
from bazz import *
from bar import *
Now, all the objects imported have types like
foo.buzz.Blob
foo.bazz.Thing
etc....
Except for the .so module, bar.so, whose objects have types like
bar.Bar
Now, I'd really like this to be
foo.bar.Bar
Is this possible? Why does 'bar.Bar' always get put in the top-level
of the name space?
Thanks,
Emil
Maarten Derickx
import foo
give what you want or is your problem different?
Emil
import foo doesn't do much, as foo/__init__.py is empty. I have
adopted the Sage-like behaviour of having an "all.py" file which has
"from bar import *" statements.
The issue is that all.py contains lines like:
from bazz import *
from bar import *
For some reason, the line corresponding to the bar.so file imports
things into the top-level of the name space, rather than as
foo.bar.xxxx. I can't find anything in the Cython docs or anywhere
else about how to stop this. The Sage Cython modules seem to be
imported into the correct places in the namespace hierarchy, so it
must be possible...
Emil
Emil
Thanks! -Emil
Robert Bradshaw
Just a guess, does placing an __init__.pxd file at that level help?
Are you compiling the .so file and then moving it into place? (The
fully qualified name of the pyx file is determined at compile time.)
Otherwise, could you try posting a tarball/repo that illustrates the
problem for someone to play around with?
- Robert
Emil
unwell, and could not respond sooner. I can't put an __init__.py file
in the top-level /site-packages directory as far as I am aware, and
I'm not sure that would be a sensible thing to do to my users...
I think my original email specifies the problem clearly:
I have a package I would like to distribute, that Sage users can
install using distutils, and I want to be able to import a
Cython-generated extension without it polluting the global namespace.
I suspect this is nothing to do with Cython, or Sage, but to do with
Python or disutils, but I am not sure... If someone could at least
clarify what area this problem fits into that would be a great help
because I can then go to the appropriate forums. Thanks,
Emil
Robert Bradshaw
> Hi Robert, thanks for taking an interest in my problem! I've been
> unwell, and could not respond sooner.
Sorry to hear that.
> I can't put an __init__.py file
> in the top-level /site-packages directory as far as I am aware, and
> I'm not sure that would be a sensible thing to do to my users...
The __init__ files need to be in the correct place during compilation,
which might be the issue.
> I think my original email specifies the problem clearly:
>
> I have a package I would like to distribute, that Sage users can
> install using distutils, and I want to be able to import a
> Cython-generated extension without it polluting the global namespace.
This should be completely doable.
> I suspect this is nothing to do with Cython, or Sage, but to do with
> Python or disutils, but I am not sure... If someone could at least
> clarify what area this problem fits into that would be a great help
> because I can then go to the appropriate forums. Thanks,
It might be distutils. It might be Cython. It might even be Sage or
Python. But without knowing exactly how you're trying to
compile/install your package, it's hard if not impossible to give any
specific recommendations on what to change to get the result you want.
- Robert
Emil
> It might be distutils. It might be Cython. It might even be Sage or
> Python. But without knowing exactly how you're trying to
> compile/install your package, it's hard if not impossible to give any
> specific recommendations on what to change to get the result you want.
Thanks Robert, but I've actually just managed to accidentally fix the problem!
I added an ext_package='...' declaration to the setup.py file, which
broke things, but when I removed it and reinstalled, everything
worked! I don't know what to make of all this.....
I'd really like to see more documentation on how to distribute
packages for Sage that are not intended to part of Sage proper. I
can't volunteer for this myself (at present) as I barely understand
how things work and have only managed to get something working by
accident.
Emil
Robert Bradshaw
> On 19 April 2012 07:20, Robert Bradshaw <robe...@math.washington.edu> wrote:
>> It might be distutils. It might be Cython. It might even be Sage or
>> Python. But without knowing exactly how you're trying to
>> compile/install your package, it's hard if not impossible to give any
>> specific recommendations on what to change to get the result you want.
>
> Thanks Robert, but I've actually just managed to accidentally fix the problem!
That's good to hear.
> I added an ext_package='...' declaration to the setup.py file, which
> broke things, but when I removed it and reinstalled, everything
> worked! I don't know what to make of all this.....
>
> I'd really like to see more documentation on how to distribute
> packages for Sage that are not intended to part of Sage proper. I
> can't volunteer for this myself (at present) as I barely understand
> how things work and have only managed to get something working by
> accident.
There should be little, if any, difference from how you would write a
Python package outside of the Sage context. (In fact, I can't think of
anything sage-specific to add...) While it's widely acknowledge that
the Python packaging ecosystem is far from ideal, looking at more
generic resources (e.g. distutils, setuptools, or in the Python
documentation itself) should help.
- Robert