Conda packages in conda-forge about spiceypy HOT 7 CLOSED

Hi @Juanlu001 thanks for writing in, I am aware of conda-forge and even looked at it a bit for learning how to make conda builds work on appveyor. I am a bit busy for the next two weeks but after that I will start looking into it. While I like the idea of being included in that channel I did end up implementing all of the benefits of conda-forge into my project (I have travis and appveyor builds and automatic artifact deployments) so I would have to evaluate this further.

from spiceypy.

No problem, ping me in two weeks and we'll discuss it. Thanks for your response!

from spiceypy.

hey sorry I lost track of this, I looked it over and I think I saw how this could be done relatively easily a few weeks ago but at the moment I don't really see why this is worth doing. I have very few anaconda users downloading spiceypy as is (I have numbers that show an order of magnitude more pip installs). Also I don't understand the need for making a separate SPICE package, it sounds like conda is being used as a package manager like homebrew or apt-get for certain c\c++ libraries which is strange. If you could outline a list of justifications for me that would be helpful.

from spiceypy.

it sounds like conda is being used as a package manager like homebrew or apt-get for certain c\c++ libraries which is strange.

It can be, but there are good reasons for it. This is an example from another field: recently I have been working with GIS Python libraries, and many of them wrap some GDAL functionality. When one does pip install gdal, it actually downloads the Python wrappers and compiles them against libgdal-dev, which is managed against the operative system.

As you can see here, the libgdal-dev version is tied to the operative system version:

https://packages.ubuntu.com/search?keywords=libgdal-dev

This means that if I want to use GDAL 2.x in latest Ubuntu LTS, I have four options:

1. Just don't do it, and use Docker or virtual machines to use a different operative system (like Arch Linux).
2. Look for some PPA.
3. Compile it by hand and put it in a different location so it doesn't break the system.
4. conda install libgdal https://anaconda.org/anaconda/libgdal/files

And this use case applies to tons of scientific Python packages.

Also I don't understand the need for making a separate SPICE package

It is not mandatory, but would help in case someone else want to wrap SPICE in a different way, or use it directly from C, or whatever.

I have very few anaconda users downloading spiceypy as is (I have numbers that show an order of magnitude more pip installs).

There might be a number of reasons for this, and it might be difficult to understand them. However, for the record I would like to say that conda install astropy from conda-forge is getting more than twice the number of downloads than from the official channel.

https://anaconda.org/search?q=astropy&sort=ndownloads&sort_order=1&reverse=true

at the moment I don't really see why this is worth doing

You don't have to, if you do not feel it's useful. I might do it myself in the future, though :) And of course I will ping you if I ever do.

from spiceypy.

hey @Juanlu001, thanks for the detailed response. This sounds more reasonable to me now, but I probably won't get to work on it until after I release 2.0.1. So if you want to work on it I say go for it!

from spiceypy.

WIP: conda-forge/staged-recipes#4115

from spiceypy.

closing this as we just got it merged

from spiceypy.