[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Bug#778417: RE:Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library



Forgot to add debian-devel back in the loop

On 02/24/2015 10:29 AM, Konrad Hinsen wrote:
> On Tue, 24 Feb 2015 06:44:54 +0000 Nick Papior Andersen
> <nickpapior@gmail.com> wrote:
> 
>> In my experience many of the features are quite similar.
>>
>> However, 
> netcdf4-python has the advantage of full CDF4 capabilities.
>> Konrads 
> excellent package allows reading a NetCDF4 format in "CLASSIC"
>> format, it 
> also allows writing the CDF3 and CDF3-64 bit files. But it does
>> not allow 
> writing the full NetCDF4 format (I do not know if he has just
>> implemented 
> it, but last time I checked, 2.9.3, he hadn't).
> 
> 
> 
> The netCDF interface in ScientificPython has no support for the
> functionality specific to netCDF4, for two reasons: (1) I don't need it
> and (2) I want to maintain compatibility with netCDF3, which is (or at
> least used to be a while ago) much less problematic to install than
> netCDF4 with its enormous dependency (HDF5).
> 
> I cannot dedicate much energy to netCDF support because I am migrating
> my own software to a direct use of HDF5. I continue to support netCDF
> merely for keeping my legacy software usable. I'd be happy to abandon my
> netCDF interface in the long run and use netcdf4-python for my legacy
> code. However, the last time I checked, this didn't look like a viable
> option.
> 
> For the pure Python interface, I could probably replace
> Scientific.IO.NetCDF by a thin wrapper on top of netcdf4-python. But for
> the C interface, I do not see a solution. I have application code (the
> Molecular Modelling Toolkit, http://dirac.cnrs-orleans.fr/MMTK/) that
> accesses a single opened netCDF file both from Python code and from C
> extension modules. To make this work portably, supporting shared
> libraries on all platforms, the C API calls must pass through the C
> extension module that is linked to the netCDF library. Last time I
> checked, netcdf4-python did not support this. Is there perhaps a
> different solution for this scenario?
> 
> Konrad.

Thanks very much to Nick and Konrad for your help here. I think there is
enough extra functionality in netcdf4-python (and I probably should
change the package name to include the 4) to warrant the effort involved
in maintaining netcdf4-python in Debian.

Checking the reverse dependencies of python-netcdf in Debian, I can see
that there are three other packages depending on it: python-tables,
python-mmtk and python-dolfin (all in the Debian Science Team). So it
would not make sense to remove python-netcdf at this point in time. But
as long as there are no namespace clashes, I see no reason to not have
both in the archive.

Cheers,

Ross

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: