search

taurus-org / taurus

Moved to https://gitlab.com/taurus-org/taurus
http://taurus-scada.org
43 stars 46 forks source link

Publish taurus to conda-forge #1172

Open beenje opened 3 years ago

beenje commented 3 years ago

taurus is currently available from the taurus-org conda channel. Is there any interest to publish it to conda-forge? The dependencies used by taurus are on conda-forge. I think it would make it easier to have taurus there as well.

cpascual commented 3 years ago

Is there any interest to publish it to conda-forge?

absolutely, yes!

Since you have experience with the tango packages, could you tell us how difficult this could be or (pushing my luck here) would you be so kind as to propose the needed changes?

beenje commented 3 years ago

Sure! The Python package has several extras_require, maybe it would be worth splitting the conda package in several outputs as well? I can prepare a PR and we can start a discussion on how to do things.

cpascual commented 3 years ago

please do!

cpascual commented 3 years ago

regarding the splitting, I trust on your judgement.

In the case of the debian packages, we also considered splitting (e.g. into taurus-core + taurus-qt), but decided against it for simplicity/maintainability, and we only separate the packaging of those parts that are already implemented as plugins in separate repos (e.g taurus_pyqtgraph ). But I hold not a strong stance about it.

beenje commented 3 years ago

I'm new to taurus, so not sure I can make that decision :-)

I think it depends on the use case. Would some users be interested in installing taurus with the minimal requirements? Or would most users install taurus-qt anyway. If that's the case, splitting might not be worth it.

cpascual commented 3 years ago

There are definitely some users who may be interested in taurus-core only without taurus-qt, but I do not know how much maintenance overhead would imply to split at conda packaging level (as opposed to splitting at repo level). In the case of splitting, however, I would like have something like taurus-core + taurus-qt + taurus (the last one being a metapackage depending on the first two).

My feeling is that unless implementing the split is quite trivial, it may not be worth (at least for a first iteration)

cpascual commented 3 years ago

Also note that it is foreseen (but probably not to be done soon) to move all the tango and epics related code to separate taurus-tango and taurus-epics plugins in their own repositories. Maybe the splitting of conda packages makes more sense at that time.

beenje commented 3 years ago

Thanks for the info! I'll probably give a try to generate subpackages for taurus-core + taurus-qt = taurus.

Regarding, epics and tango dependencies, in both case, it's currently just one extra package to add. So I don't think it makes sense to add a specific subpackage for those. Users can manually add pyepics or pytango to their environment. When plugins are created, then new packages will be required anyway.

beenje commented 3 years ago

Draft PR: https://github.com/conda-forge/staged-recipes/pull/13756

beenje commented 3 years ago

taurus is on conda-forge! https://github.com/conda-forge/taurus-feedstock

Shall we continue with taurus_pyqtgraph? And sardana?

cpascual commented 3 years ago

Thank you so much! This is a huge improvement.

Shall we continue with taurus_pyqtgraph?

Yes please!

And sardana?

I guess yes, but it is better to open an issue in the sardana project so that the sardana team can confirm. Note that, AFAIK, they do not have a conda recipe done yet.

cpascual commented 3 years ago

I'll leave this issue open as a reminder until we adapt the docs.

cpascual commented 3 years ago

I tested the installation using conda install -c conda-forge taurus on linux and on win10, and it worked fine.

Note: In the case of windows, pytango is not yet available in conda-forge. If tango is wanted, one still needs to use the tango-controls channel