Add scikit-build #1989
Add scikit-build #1989
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
||
test: | ||
imports: | ||
- skbuild |
jcfr
Nov 23, 2016
Contributor
Would it make sense to run the full test suite ?
Would it make sense to run the full test suite ?
isuruf
Nov 23, 2016
Author
Member
Yes, how do I run the full test suite?
Yes, how do I run the full test suite?
jcfr
Nov 23, 2016
Contributor
pytest
or python setup.py test
will work
pytest
or python setup.py test
will work
Sure, feel free to add me. |
@isuruf Thanks for contributing the recipe. You rock !
I wonder if it would make sense to run the full test suite
I would be happy to learn. My experience with conda recipe is limited. In the mean time, your help is very much appreciated Cc: @thewtex |
I'm getting test failures. See build log here, https://circleci.com/gh/isuruf/staged-recipes/104 Most tests fail because cmake can't find |
This comment has been minimized.
This comment has been minimized.
Can add me if you want. I should be able to help more soon. |
I've disabled the 3 tests that are failing (2 that check the directory name and the one that checks for the fortran compiler.) Ready for a final review now |
script: | ||
- python setup.py install --single-version-externally-managed --record record.txt | ||
# Tests are skipped for now. | ||
- py.test -k "not (test_push_dir or test_fortran_compiler)" |
scopatz
Nov 23, 2016
Member
This should be in the test block (not the build block) and should be under the "commands" block (which lives at the same level as "imports")
This should be in the test block (not the build block) and should be under the "commands" block (which lives at the same level as "imports")
isuruf
Nov 23, 2016
Author
Member
Tests are not installed, so this has to be done in build phase.
Tests are not installed, so this has to be done in build phase.
scopatz
Nov 23, 2016
Member
You can cd to the source directory in the test phase. This is what many recipes do.
You can cd to the source directory in the test phase. This is what many recipes do.
isuruf
Nov 23, 2016
Author
Member
Can you give an example recipe that does this?
Can you give an example recipe that does this?
scopatz
Nov 23, 2016
Member
This is why we need docs, example at https://github.com/conda-forge/cyclus-feedstock/blob/master/recipe/run_test.sh#L3
This is why we need docs, example at https://github.com/conda-forge/cyclus-feedstock/blob/master/recipe/run_test.sh#L3
isuruf
Nov 23, 2016
Author
Member
- python | ||
- setuptools | ||
- wheel | ||
# Following dependencies are for testing needed in build phase |
scopatz
Nov 23, 2016
Member
Test dependencies should be in the "test" section in the "requires" section.
Test dependencies should be in the "test" section in the "requires" section.
@isuruf - please see other recipes and the conda build docs for more info on testing. Or feel free to ask questions |
Better way with conda build 2 is to use the test/source_files entry to On Nov 23, 2016 2:07 PM, "Isuru Fernando" notifications@github.com wrote:
|
@isuruf Thanks for your persistence |
This commit increases the robustness of the test and should ensure it pass when executed on conda-forge ci. See conda-forge/staged-recipes#1989 Suggested-by: Isuru Fernando <isuruf@gmail.com>
# string IDs seem to be just the vs_base. | ||
|
||
self.default_generators.insert(0, vs_base) | ||
+ self.default_generators.insert(1, "NMake Makefiles") |
isuruf
Nov 24, 2016
Author
Member
scikit-build test-suite doesn't like the fact that Visual Studio 9 2008 Win64 fails, but NMake doesn't.
> assert(get_best_generator() == generator)
E assert 'NMake Makefiles' == 'Visual Studio 9 2008 Win64'
scikit-build test-suite doesn't like the fact that Visual Studio 9 2008 Win64 fails, but NMake doesn't.
> assert(get_best_generator() == generator)
E assert 'NMake Makefiles' == 'Visual Studio 9 2008 Win64'
@msarahan, conda-forge is using conda-build 2.0.10, but test/source_files is not supported |
sorry about the confusion, it's using 1.2.14 |
# string IDs seem to be just the vs_base. | ||
|
||
self.default_generators.insert(0, vs_base) | ||
+ self.default_generators.insert(0, "NMake Makefiles") |
isuruf
Nov 24, 2016
•
Author
Member
I've changed this to make NMake Makefiles
the default for win and py27 and x86_64
. I see that in scikit-ci-addons, this is fixed in appveyor by running a script that needs elevated permissions, which a user might not have. I think there is no harm in trying NMake first before trying a Visual Studio project. Any objections or other suggestions?
I've changed this to make NMake Makefiles
the default for win and py27 and x86_64
. I see that in scikit-ci-addons, this is fixed in appveyor by running a script that needs elevated permissions, which a user might not have. I think there is no harm in trying NMake first before trying a Visual Studio project. Any objections or other suggestions?
@@ -0,0 +1,13 @@ | |||
MSVC 9 x64 is broken on appveyor. Use NMake there. |
jcfr
Nov 24, 2016
Contributor
It could easily be fixed using the patch_vs2008
add-on provided by scikit-ci-addons
See http://scikit-ci-addons.readthedocs.io/en/latest/addons.html#patch-vs2008-py
It could easily be fixed using the patch_vs2008
add-on provided by scikit-ci-addons
See http://scikit-ci-addons.readthedocs.io/en/latest/addons.html#patch-vs2008-py
isuruf
Nov 24, 2016
Author
Member
Yes, there is also a conda package that does this, https://github.com/conda-forge/vs2008_express_vc_python_patch-feedstock
But this is discouraged because this requires admin privileges. cc @jakirkham
Yes, there is also a conda package that does this, https://github.com/conda-forge/vs2008_express_vc_python_patch-feedstock
But this is discouraged because this requires admin privileges. cc @jakirkham
jcfr
Nov 24, 2016
Contributor
I created an issue in scikit-build to better support Microsoft Visual C++ Compiler for Python 2.7. See scikit-build/scikit-build#216 for more details.
I created an issue in scikit-build to better support Microsoft Visual C++ Compiler for Python 2.7. See scikit-build/scikit-build#216 for more details.
jcfr
Nov 24, 2016
•
Contributor
requires admin privileges.
I think in practice it is reasonable to assume developers have admin privileges on their workstation.
Similarly to the installation of recent Visual Studio (e.g VS2015 for Python3.5) already requiring admin privileges, expecting developer to patch their install of Visual Studio 2008 express seems fair.
That said, installing arbitrary patches to modify an official installation could be a problem here and supporting " Microsoft Visual C++ Compiler for Python 2.7" would be a more sane alternative.
requires admin privileges.
I think in practice it is reasonable to assume developers have admin privileges on their workstation.
Similarly to the installation of recent Visual Studio (e.g VS2015 for Python3.5) already requiring admin privileges, expecting developer to patch their install of Visual Studio 2008 express seems fair.
That said, installing arbitrary patches to modify an official installation could be a problem here and supporting " Microsoft Visual C++ Compiler for Python 2.7" would be a more sane alternative.
jakirkham
Nov 28, 2016
Member
Yeah, my thinking is we will install those patches in the CI beforehand as they are valuable occasionally. However, trying to use Microsoft Visual C++ Compiler for Python 2.7 is preferable.
Yeah, my thinking is we will install those patches in the CI beforehand as they are valuable occasionally. However, trying to use Microsoft Visual C++ Compiler for Python 2.7 is preferable.
@isuruf Thanks for driving this forward. This is excellent! |
This reverts commit 4a0fdd6.
I've reverted the last commit and will use a better patch coming out of scikit-build/scikit-build#216. |
This seems reasonable to me. Any objections to merging? |
No objections from me. Looks good. |
Thanks All! |
Thanks a lot |
commands: | ||
- cd ${SRC_DIR} && py.test -k "not (test_push_dir or test_fortran_compiler)" # [unix] | ||
- cd %SRC_DIR% && py.test -k "not (test_push_dir or test_fortran_compiler)" # [win and not (py27 and x86_64)] | ||
- cd %SRC_DIR% && py.test -k "not (test_push_dir or test_fortran_compiler or test_generator_selection or test_hello_builds_with_generator)" # [win and py27 and x86_64] |
jakirkham
Nov 28, 2016
Member
Something to keep in mind is we had problems with these x86_64
selectors recently in our maintenance scripts. ( conda-forge/dmd-feedstock#2 ) We may need to change the feedstock not to use these.
Something to keep in mind is we had problems with these x86_64
selectors recently in our maintenance scripts. ( conda-forge/dmd-feedstock#2 ) We may need to change the feedstock not to use these.
@jcfr, @msarahan, @scopatz let me know if you are interested in maintaining this.
@jcfr, can you take a look at the build and run requirements and see if any package is missing?