You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the dependencies are not specified in setup.py, it is impossible to install slycot via pip install -r requirements.txt, even if you add all dependencies to requirements.txt, because the build fails if scikit-build isn't installed before slycot.
Therefore we should at least add setup_requires=['scikit-build'].
Seems reasonable to add setup_requires. Here is the description from the setuptools docs:
setup_requires
A string or list of strings specifying what other distributions need to be present in order for the setup script to run. setuptools will attempt to obtain these (even going so far as to download them using EasyInstall) before processing the rest of the setup script or commands. This argument is needed if you are using distutils extensions as part of your build process; for example, extensions that process setup() arguments and turn them into EGG-INFO metadata files.
(Note: projects listed in setup_requires will NOT be automatically installed on the system where the setup script is being run. They are simply downloaded to the ./.eggs directory if they’re not locally available already. If you want them to be installed, as well as being available when the setup script is run, you should add them to install_requires and setup_requires.)
Closed issue #61 is pretty much the same thing as this. I just installed numpy, scikit-build, and slycot (in that order) in a clean virtual-env; pip claimed to have installed slycot, but as in #63 I then get "No module named 'slycot'", so I get the idea we don't have an install-from-pip capability.
Specific to this issue: if we add scikit-build to 'setup-requires', does that mean The Right Thing would happen if we installed from pip, i.e., it would first install scikit-build?
What does this have to do with requirements.txt? When would we use that?
And finally, is there a way we can test this without uploading wheels to PyPI?
My current test method is, in a venv with numpy and scikit-build installed, to build a source distribution, and then, in a venv without numpy and scikit-build, run pip install slycot-<version>.tar.gz.
So far this fails with the following:
setup_requires=['scikit-build'] added to metadata in setup.py
the following added to setup.cfg.in
[options]
setup_requires =
numpy
scikit-build
I see scikit-build recommend using pyproject.toml on their page, but setuptools docs say that setup.cfg has "broader compatibility".
On this branch https://github.com/roryyorke/Slycot/tree/rory/pip-fixes I can generate an sdist and then install it with pip, but "python setup.py install" fails, so the Conda builds all fail. The failure is due to the installed files ending up in the wrong place; I assume it has something to do with CMAKE_INSTALL_PREFIX, but I'm not sure how to debug it.
This is either a mistake in how we're using scikit-build, or a bug in that package; either way, I've opened an issue asking for help here: scikit-build/scikit-build#424
Activity
MaxGaukler commentedon May 23, 2019
If the dependencies are not specified in setup.py, it is impossible to install slycot via
pip install -r requirements.txt, even if you add all dependencies to requirements.txt, because the build fails if scikit-build isn't installed before slycot.Therefore we should at least add
setup_requires=['scikit-build'].moorepants commentedon May 23, 2019
Seems reasonable to add
setup_requires. Here is the description from the setuptools docs:setup_requires
A string or list of strings specifying what other distributions need to be present in order for the setup script to run. setuptools will attempt to obtain these (even going so far as to download them using EasyInstall) before processing the rest of the setup script or commands. This argument is needed if you are using distutils extensions as part of your build process; for example, extensions that process setup() arguments and turn them into EGG-INFO metadata files.
(Note: projects listed in setup_requires will NOT be automatically installed on the system where the setup script is being run. They are simply downloaded to the ./.eggs directory if they’re not locally available already. If you want them to be installed, as well as being available when the setup script is run, you should add them to install_requires and setup_requires.)
roryyorke commentedon May 25, 2019
Closed issue #61 is pretty much the same thing as this. I just installed numpy, scikit-build, and slycot (in that order) in a clean virtual-env; pip claimed to have installed slycot, but as in #63 I then get "No module named 'slycot'", so I get the idea we don't have an install-from-pip capability.
Specific to this issue: if we add scikit-build to 'setup-requires', does that mean The Right Thing would happen if we installed from pip, i.e., it would first install scikit-build?
What does this have to do with requirements.txt? When would we use that?
And finally, is there a way we can test this without uploading wheels to PyPI?
roryyorke commentedon May 25, 2019
My current test method is, in a venv with numpy and scikit-build installed, to build a source distribution, and then, in a venv without numpy and scikit-build, run
pip install slycot-<version>.tar.gz.So far this fails with the following:
setup_requires=['scikit-build']added to metadata in setup.pyI see scikit-build recommend using pyproject.toml on their page, but setuptools docs say that setup.cfg has "broader compatibility".
roryyorke commentedon May 26, 2019
On this branch https://github.com/roryyorke/Slycot/tree/rory/pip-fixes I can generate an sdist and then install it with pip, but "python setup.py install" fails, so the Conda builds all fail. The failure is due to the installed files ending up in the wrong place; I assume it has something to do with
CMAKE_INSTALL_PREFIX, but I'm not sure how to debug it.roryyorke commentedon May 26, 2019
This is either a mistake in how we're using scikit-build, or a bug in that package; either way, I've opened an issue asking for help here: scikit-build/scikit-build#424