Bugzilla Bug 54161

Opendap extends Python and Numeric to give access to the immense data sets on
Distributed Oceanographic Data Servers (DODS).

Suggest that this should go in the app-sci directory.

Created an attachment (id=33409) [details]
opendap-1.2.3.ebuild

Created an attachment (id=33462) [details]
opendap-1.2.3.ebuild

Created an attachment (id=59974) [details]
opendap-1.3.1.ebuild

Created an attachment (id=73625) [details]
opendap-2.0.0

Server is much improved over 1.3.1.  Now has some real documentation.

Project developer renamed project to pydap.

Created an attachment (id=78914) [details]
pydap ebuild

Requires the patch that I am going to upload in a moment.

Created an attachment (id=78915) [details]
Patch to remove any reference to easy_setup, Python eggs, ...etc.

pydap is trying to use 'setuptools'.  This might be a big gain sometime in the
future, but right now... 

Removed all reference to 'setuptools'

Created an attachment (id=79403) [details]
pydap-2.1.3.ebuild

Created an attachment (id=79404) [details]
files/01_ez_setup_isnt.diff

Created an attachment (id=86903) [details]
pydap-2.1.4.ebuild

Changed the ebuild so the patch was no longer required.

Changing the name to 'dap' makes things along easier in the ebuild.

Created an attachment (id=99130) [details]
dap-2.2.0.ebuild

Ebuild looks very similar to what I ended up creating here.  However, I found
that the package depended on dev-python/fpconst as well as on httplib2 (not in
portage).  Without these packages, I was getting exceptions when running some
dap examples. Also, are you sure that it has a hard dependancy on Numeric?  I
can't find an import statement for numeric, but I _can_ find one for numpy
(dev-python/numpy).

This ebuild won't install for me without setuptools.  

Thanks Ryan.  I haven't really paid too much attention and things have changed
that I didn't keep up with.  Sorry.

You saw that I submitted a dev-python/httplib2 ebuild shortly ahead of yours
that should address that particular dependency.

I am thinking it would be best to have a 'server' USE variable; without it set
you get the client (just a few dependencies) and with 'server' set you get the
server (a whole bunch of dependencies - including Cheetah and most of Paste). 
What do you think? 

The numpy import is optional. If numpy is available then it is used to make
some of the calculations faster. Since nothing is lost except for speed I don't
think it should be a dependency.

The server useflag sounds reasonable.  The reason I mentioned the numpy is
because formerly, numeric was listed as a dependancy, but I don't think it is
used any more.  It looks like the source only import numpy if it's available,
so I think it's fine if numpy isn't listed as a dependancy.

Created an attachment (id=99845) [details]
sci-misc/dap-2.2.2.ebuild

Now uses a 'server' USE variable that when set has additional dependencies. 
The client needs dev-python/httplib2 and the server needs dev-python/paste and
dev-python/cheetah.  httplib2 and paste have been submitted to bugs.gentoo.org.

Created an attachment (id=100158) [details]
sci-misc/dap-2.2.2.ebuild

Streamlined the code.

Created an attachment (id=102167) [details]
sci-misc/dap-2.2.5.1.ebuild

Now remove the 'requires.txt' file to prevent setuptools from checking for
requirements when you try to import dap.  Setuptools would fail to find
httplib2 even if it was installed since httplib2 didn't have an egg-info
directory.  Of course this makes no sense, but blame setuptools.

Created an attachment (id=105347) [details]
sci-misc/dap-2.2.5.7

* Fixed a problem with easy install trying to manage dependencies.
* Bumped to latest version.

I just tested this package (haven't in awhile), and noticed as is, python
throws an exception when I try to run:

import dap

It seems that it doesn't like that there isn't a __init__.py in the
/usr/lib/python2.4/site-packages/dap directory.  Simple adding an empty one
fixed the problem.  Any ideas?

Darn, you are right.  I vaguely remember creating an __init__.py the same as
you, but forgot to include it into the ebuild.

I can update the ebuild to make the __init__.py (within the week?) or if you
are willing and have some time - please have a go.  I think you could use the
'echo' command and just direct a blank line to __init__.py?  

Kindest regards,
Tim

(From update of attachment 105347 [details])
Version bump.
I unmerged the old dap version, deleted the directory (to get rid of the
__init__.py) and emerged this version.  Import seems to work so the import bug
is fixed upstream.

Hi,

Thanks for your work.
We finally have dev-python/dap-2.2.6.3 in the tree, which I had to add for
basemap. I am not familiar with the package, so please test it.
This last version had changed a bit the dependencies the ebuilds submitted
here.

With dap installed, anything that uses pkg_resources (scipy, pytz) spits out
the following warning:

/usr/lib64/python2.5/site-packages/scipy/__init__.py:18: UserWarning: Module
dap was already imported from None, but /usr/lib64/python2.5/site-packages is
being added to sys.path

It's kind of annoying to see all the time, what can we do about this?

Thanks Sébastien!

Just uninstalled sci-misc/dap and installed dev-python/dap.  I use paludis as
my package manager and it choked on dev-python/dap.  It was seeing '/server'
for the USE keyword rather than 'server'.  I deleted and reinserted the leading
tab and made sure there was a line ending on the previous line.  Then
dev-python/dap installed fine.

Have yet to test it though.  Will get back to you on that.

What about all of the plugins? 

And a little thing - why dev-python?

Kindest regards,
Tim

> /usr/lib64/python2.5/site-packages/scipy/__init__.py:18: UserWarning: Module
> dap was already imported from None, but /usr/lib64/python2.5/site-packages is
> being added to sys.path

You are right. I am not an egg expert, but I looked around the code and it
seems namespace related. If we remove the pth file it seems working, I don't
know how much it hurts egg users.


> my package manager and it choked on dev-python/dap.  It was seeing '/server'
> for the USE keyword rather than 'server'. 

Yes, it was fixed later on and you probaly synced before. Sorry about that.

> What about all of the plugins? 
> 
> And a little thing - why dev-python?

I did not realize about the plugins! I was just pushing this as a dependency
for basemap. The python team is working on a g-pypi tool that should take care
of all python eggs transparently, similar to the g-cpan for perl. I am not sure
that implementing all the plugins would be worth the effort then. May be the
science overlay meanwhile.
As for dev-python, just a matter of taste :)

(In reply to comment #28)
> > /usr/lib64/python2.5/site-packages/scipy/__init__.py:18: UserWarning: Module
> > dap was already imported from None, but /usr/lib64/python2.5/site-packages is
> > being added to sys.path
> 
> You are right. I am not an egg expert, but I looked around the code and it
> seems namespace related. If we remove the pth file it seems working, I don't
> know how much it hurts egg users.

Removing the .pth file seems to break certain other packages that rely on
namespace package functionality of setuptools.  However, I found that if I add
'dap' to the top of the file namespace_packages.txt under the
/usr/lib/python2.5/site-packages/dap-2.2.6.3-py2.5.egg-info directory, it fixes
the messages, and AFAICT, dap still works.

time to close that one.