Open RileyWilliams opened 8 years ago
I have a fix for this and yes you are right we need to install it via conda install. We could set up such a mechanism for the build ecosystem. You can see something similar we did with Apache OCW at https://github.com/apache/climate/blob/master/.travis.yml#L24 this essentially points to the script at https://github.com/apache/climate/blob/master/easy-ocw/install-ubuntu.sh
So would you suggest using a combination of pip and conda? or just using conda? I have uploaded an OSX_64 package onto anaconda, and am working on other platforms. Do you think using coda alone is a viable option? Or would an install.sh script or similar work? (only issue with this is that there will have to be different scripts for each os). My aim is to make the package installable with only one command, so that people actually use it! 😜
My aim is to make the package installable with only one command, so that people actually use it!
Exactly and I back you up on this one. The thing over on OCW is that having the scripts which in turn use conda and pip has ended up a wee bit messy. I would suggest, if possible, we should stick to conda packaging.
I have now added a build for 64bit linux, however, this method means that the code has to be built on each system before upload to anaconda. Which could be fairly time consuming if this has to be done for each release. Is there a better way of doing this?
Hi @RileyWilliams yes there undoubtedly is. The conda packaging exists right? Does this not address our requirements?
Hi Folks, I recently started using conda-forge for publishing my Python packages to conda. Examples are podaacpy, pycoal and spectral. Are you guys interested in developing a conda-forge recipe for pycovjson? If so then I can undertake the work no problems at all.
It does not seem possible to install netCDF4 using pip without running into errors with hdf5. Potential workaround would be switching to hosting the package on anaconda, but this is not ideal.