Open hmaarrfk opened 3 years ago
cc: @bilderbuchi
I think it is best to delay the dependency on pyqt
By delay you mean do not declare? If this lib depends on pyqt, as built, then that should be declared. If we build a variant that depends on pyside2 then great, we can think about how to handle that. But this is built against pyqt AFAIK and therefore needs to depend on it.
we can think about how to handle that
the thing is, pyqtgraph depends on either pyqt or pyside (the user could use either), but not none of them (so run_constrained
is not sufficient).
From what I could see there is currently no way to declare such a dependency relationship: a
or b
, a
xor b
, with a default if no user preference is given or set by other constraints. Is that correct? Would such a feature be desirable for conda?
You'd use a variant package and build strings, probably. Similar to how blas is handled. Pinging @isuruf for recommendations here.
Yes a mutex package named pyside_or_pyqt
with two variants will be the best solution.
Yes a mutex package named pyside_or_pyqt with two variants will be the best solution.
I like that this would centralize the complexity, and not force every downstream package to have two builds.
The conda-forge package removed the dependency on pyqt to allow downstream users to choose pyside2 instead of pyqt.
A user has brought up the fact that this doesn't line up with what is happening in the default recipes.
It might be good for the two packages to align, but I guess thereare differences in the downstream details.
I just wanted to bring this up.
I think it is best to delay the dependency on pyqt.
Let me know what you think
https://github.com/conda-forge/pyqtgraph-feedstock/pull/15#issuecomment-712820396