Package Details: python2-pyhdf 0.10.1-1

Git Clone URL: https://aur.archlinux.org/python-pyhdf.git (read-only, click to copy)
Package Base: python-pyhdf
Description: Python bindings for the HDF4 library
Upstream URL: https://github.com/fhs/pyhdf
Licenses: MIT
Submitter: fhs
Maintainer: fhs
Last Packager: fhs
Votes: 7
Popularity: 0.000000
First Submitted: 2019-03-23 23:24 (UTC)
Last Updated: 2019-03-24 01:32 (UTC)

Latest Comments

1 2 Next › Last »

djscholl commented on 2012-03-11 18:25 (UTC)

Arch version bump to revert to the dependency on hdf4-nonetcdf, thanks to Arch user giniu.

giniu commented on 2012-03-11 09:29 (UTC)

Now I have same conflict as before - my package requires both python2-pyhdf and python2-netcdf4. Now, the problem is that hdf4 provides netcdf and conflicts with netcdf package, which is required by python2-netcdf4 (which in turn cannot work with netcdf provided by hdf4) - standard way to do this, like most distributions does - is to disable netcdf in hdf and it works like a charm. I'd like to ask for switching back to hdf4-nonetcdf - that package was flagged as out of date only two days ago, lets give its maintainer a chance to update it before switching and introducing conflicts only to use minor update in dependency few days earlier (4.2.6 vs 4.2.7). At least that's my opinion about it :)

djscholl commented on 2012-03-11 02:09 (UTC)

Arch version bump to update the dependency, thanks to Arch user jeruntu.

jeruntu commented on 2012-03-10 16:43 (UTC)

The dependency hdf4-nonetcdf is outdated, it should use hdf4 2.7-1 instead.

giniu commented on 2011-02-14 13:03 (UTC)

cool :)

djscholl commented on 2011-02-14 12:45 (UTC)

The python2-pyhdf package is available now: https://aur.archlinux.org/packages.php?ID=46498

djscholl commented on 2011-02-14 12:43 (UTC)

Update of pyhdf: improved package name and fixed NetCDF-related package conflicts, thanks to Arch user Giniu.

djscholl commented on 2011-02-14 03:41 (UTC)

I bumped the Arch version to fix package names, license file, minor PKGBUILD format items. This makes it more useable for anyone who wants the netcdf functionality in the future. I will introduce a python2-pyhdf without netcdf as suggested by Giniu.

giniu commented on 2011-02-12 13:42 (UTC)

Hi. About maintaining this package, I think you are doing good job. I already have quite a lot of packages (93 currently, though maybe half of them are -git, -hg or -svn so it doesn't take that much time, but still I'm checking if they build and stuff like that). I think that when it will be updated for python2 it could be left alone for some time, so to say, I'd prefer to help by giving feedback :) I think we don't need pyhdf-nonetcdf. The only functionality that gets lost is reading of cdf file, while developers recommends using pycdf for this, which can also write them. That way we avoid conflicts. Also, hdf4 and pyhdf are here only for legacy applications, so I don't think that removing it would break too much, especially that there are no packages that depend on it here in AUR. If someone needs cdf files support, he can use pycdf. About library naming, I believe it would be better to name it python2-pyhdf, unless python-pyhdf already existed - at least that's what I did for ETS. I think it's better to have possibly all python 2 packages starting with python2-, then you can check your python 2 libraries with "pacman -Qs python2-" and python 3 libraries with "pacman -Qs python-", while creating more python 2 libraries with names starting with python- instead of python2- makes it harder to determine without looking at dependencies. Of course, if there was already python- and the lib is python 2 only, it doesn't make sense to create new package and leave old one behind unmaintained/unused. New name also solves other issue, if someone really really wants to use pyhdf with netcdf support, he would be able to use legacy pyhdf package, while python2-pyhdf could be hdf4-nonetcdf version. At least I think that this is good solution. Cheers, Giniu.

djscholl commented on 2011-02-12 12:54 (UTC)

Giniu, thank you for your comments. I no longer use this library, so I do not know how this specialized area is evolving, and I am not able to test the package. I am willing to continue to maintain this package, relying on user comments such as yours. I am also willing to orphan this package, if you have the time and interest to volunteer to become maintainer. Please feel free to tell me your preference. I think this package should be renamed to reflect its status as a python library, not an application, according to https://wiki.archlinux.org/index.php/Python_Package_Guidelines We could use python-pyhdf for now, and if/when the upstream goes to python3, change python-pyhdf to 3 and add python2-pyhdf. Alternatively, we could begin with python2-pyhdf. My understanding of the keep-it-simple philosophy is not to specify python2-pyhdf unless there is, or will soon be, a python-pyhdf as well. I suppose opinions may vary on this point. It appears to me that the python-netcdf4 maintainer has not changed to python2-netcdf4. I also wonder whether we should support both with and without netcdf. Following the hdf4-nonetcdf example, should we have both python-pyhdf and python-pyhdf-nonetcdf? This seems more consistent than having python-pyhdf and python-pyhdf-netcdf. However, I don't know whether there would be any users for the version with netcdf, given the conflicts you describe. Creating packages that no one wants is not keep-it-simple, either. I look forward to reading your reply on these issues.

1 2 Next › Last »