Summary: | sci-misc/dap-2.2.5.7.ebuild (new package) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tim Cera <tim> |
Component: | New packages | Assignee: | Sci-geo Project <sci-geosciences> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | rmay31, tim |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://pydap.org | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 130866, 150691, 152282 | ||
Bug Blocks: | 150479, 150481, 150482, 150484 | ||
Attachments: |
opendap-1.2.3.ebuild
opendap-1.2.3.ebuild opendap-1.3.1.ebuild opendap-2.0.0.ebuild pydap-2.1.1.ebuild Patch to remove any reference to easy_setup, Python eggs, ...etc. pydap-2.1.3.ebuild files/01_ez_setup_isnt.diff pydap-2.1.4.ebuild dap-2.2.0.ebuild sci-misc/dap-2.2.2.ebuild sci-misc/dap-2.2.2.ebuild sci-misc/dap-2.2.5.1.ebuild sci-misc/dap-2.2.5.8.ebuild |
Description
Tim Cera
2004-06-16 20:34:50 UTC
Created attachment 33409 [details]
opendap-1.2.3.ebuild
Created attachment 33462 [details]
opendap-1.2.3.ebuild
Created attachment 59974 [details]
opendap-1.3.1.ebuild
Created attachment 73625 [details]
opendap-2.0.0.ebuild
Server is much improved over 1.3.1. Now has some real documentation. Project developer renamed project to pydap. Created attachment 78914 [details]
pydap-2.1.1.ebuild
Requires the patch that I am going to upload in a moment.
Created attachment 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 attachment 79403 [details]
pydap-2.1.3.ebuild
Created attachment 79404 [details, diff]
files/01_ez_setup_isnt.diff
Created attachment 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 attachment 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 attachment 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 attachment 100158 [details]
sci-misc/dap-2.2.2.ebuild
Streamlined the code.
Created attachment 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 attachment 105347 [details]
sci-misc/dap-2.2.5.8.ebuild
* 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 Comment on attachment 105347 [details]
sci-misc/dap-2.2.5.8.ebuild
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. |