Replies: 1 comment 1 reply
-
|
I think it's about letting the user have some capability even if they cannot install Slycot. Slycot is a pain to compile, especially on Windows, so this way we make python-control available to users who can't use conda. The current situation seems OK to me. I think minimum requirements to make Slycot a hard dependency would be (1) Slycot is reliably pip-installable; (2) Slycot maintainers (Ben, Richard, myself) commit to keeping it that way. Given the state of Python packaging of BLAS-dependent packages, that won't happen anytime soon. |
Beta Was this translation helpful? Give feedback.
-
|
Ah didn't know about the Windows headaches. Thanks for the insight. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
Is there a particular reason why we have slycot as an optional dependency?
Many new people (like myself) will run into balking functions that berate you for not having slycot installed.
Also our test-effort is increased because we test the 'no slycot' case seperately.
It would settle my discomfort if someone could give me the 'aha!' reason for this.
Note: I don't want to reopen the 'should we replace it?' discussion of years back.
I just kinda want to give in to the fact, that we will probably stay dependent on it and we might as well formalize that.
Thanks,
Henk van der Laak
Beta Was this translation helpful? Give feedback.
All reactions