-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing (optional) dependencies #885
Comments
I suggest we add those dependencies as optional dependencies in I am thinking we could also group them by facility and/or beamline. So we could have optional groups of dependencies (also called extras) such as But I need help with that, to figure out what facility is running what exactly, especially which versions so that they can be added to |
These are the missing imports I have identified so far:
|
Then maybe all those imports could/should be wrapped in a |
Some facilities/beamline might be using a mix, so having specific groups of dependencies would be tedious. I am fairly certain that beamlines using Epics don't mix with Pytango/Taco/Sardana but they might use Exporter .... So far it seems to only impact the generation of the documentation. |
As @AnnieHeroux pointed out its not uncommon that there is a mix of the various dependencies and that many of these are not exclusive to only one site. In that case each site has to maintain their section in the Maybe adding a section that is maintained by each site makes this work easier ? I think its important that we keep things as straightforward as possible, it would probably not help if one needs to pass tons of things to --with. For the |
@AnnieHeroux, I do not know that there would be a problem here. Each facility can maintain their own list of optional dependencies for themselves if they want to. And we can have some other list(s) that are based by topic. Something like this (probably not this exact notation, I still need to figure this out): [tool.poetry.extras]
bliss = ["bliss"]
pymba = ["pymba"]
redis = ["redis"]
sardana = ["sardana"]
tango = ["PyTango"]
v4l2 = ["v4l2"]
vapory = ["Vapory"]
maxiv = ["mxcubecore[sardana,tango]"] In this example, maxiv = ["PyTango", "sardana"] Goal is to have all dependencies clearly listed somewhere (in |
Regarding the above list :
A problematic details will be that each site (or even beamline) might want to use different versions of the same dependency, |
@marcus-oscarsson Thanks for the list :)
Yes, I am also worried about this. But maybe there is a compromise to be made somewhere. We can investigate. If you know which version ranges ESRF needs/wants for their optional dependenices, I can slowly start building this. We'll see how far we can get before things start to break (version conflicts). |
This one goes unnoticed because it was already in a
|
Thanks @AnnieHeroux, I added to my list. By chance, do you know what needs to be installed for the Python import to work, is it a package available on PyPI or conda? |
i tried Matt thinks many facility/beamlines may do their own thing about epics import (conda or Pypi or ???) |
GitHub: fixes mxcube#885
I started a draft pull request to experiment with this: #900 |
GitHub: fixes mxcube#885
GitHub: fixes mxcube#885
GitHub: fixes mxcube#885
As a result of investigating this: #874 (comment)
I now realize there are a bunch of imports in the code base that are not associated with a dependency in
pyproject.toml
.As a side effect it triggers a whole bunch of errors and warnings when build the documentation (the auto-generated API part of the documentation).
Maybe we can fix that.
The text was updated successfully, but these errors were encountered: