-
Notifications
You must be signed in to change notification settings - Fork 108
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
Add conda recipe #261
Add conda recipe #261
Conversation
Codecov Report
@@ Coverage Diff @@
## master #261 +/- ##
===========================================
- Coverage 83.50% 72.61% -10.90%
===========================================
Files 22 22
Lines 3268 3268
===========================================
- Hits 2729 2373 -356
- Misses 539 895 +356
Continue to review full report at Codecov.
|
9f8de1a
to
e23195b
Compare
For compatibility with current CI
e23195b
to
4ba79c3
Compare
This shouldn't affect coverage, there is an old test failure that appears to be stuck to this PR because I rebased a few things. |
Hi, thanks for doing this! First, in terms of the conda recipe itself I have two comments:
Moreover, I've had some discussions with lab members regarding |
It is possible to compile the IPOPT interfaces at build time, but not require the Regarding IPOPT's I am happy to submit the |
This would be pretty cool. Since I'm very unfamiliar with conda, I have a few more questions (assuming we get this on conda-forge):
Yeah, I agree. This is a good solution for now, but I can try to add this feature to pyOptSparse in the future.
Yeah that's totally reasonable. I think I can commit to this, and in the future hopefully others in the lab can be added too. I'm just hesitant because I (and others in the lab) have very limited experience with conda, but if this is mostly just maintaining some YAML files and the build/test process is largely automated, then I'm less worried. |
I have experience with conda-packaging for internal deployment, but this would be my first time submitting to conda-forge. So prefix everything below with "AFAIK."
Yes, conda-forge will build the necessary interface binaries and bundle those (along with the python sources) into the conda package. When pyIPOPT is imported, it will try to import
conda-forge supports multi-platform builds on a matrix of platforms which is defined along with the recipe. So we can have it build on whichever platforms this package supports. So there will be multiple versions of
Yep, we'll need to make some minor changes. And
There shouldn't be too much babysitting or CI administration, as that's all handled by conda-forge. Hopefully it isn't too much work, and I will support the best that I can. I'll put in the PR for I'm happy to discuss any questions you have about those PRs, or conda packaging in general. I think it would be a huge benefit to the community if more of the mdolab tools were available on conda-forge, and this is probably a good first step. I appreciate all the effort of you and your group. So thank you, and thanks for entertaining this! |
Sounds like a plan! I don't think the maintainer group will work since that's specific to the No thank you for getting this started, it has been requested several times but we were sort of waiting for a PR since we were unfamiliar with conda ourselves. We can discuss the specifics on the PR to As for other mdolab codes, we had talked about that internally, but since it doesn't usually fall under our use case within the lab there has been low enthusiasm to do that. But I think pyOptSparse occupies a unique place since 1) it's used by many outside the lab, and 2) it would benefit a lot from conda. Let's start here and see where things go, it's possible that in the future we may support more packages. |
The conda-forge recipe is now open here: conda-forge/staged-recipes#15239. Closing this PR! |
Purpose
Add recipe to build pyoptsparse as a conda package.
The conda package supports all the standard (free) optimizers, plus IPOPT (which it introduces as a build and run-time conda dependency). This all happens under the hood, so users don't need to mess around building IPOPT from source. The particular flavor of metis/mumps dependencies you get is chosen by the maintainers of the IPOPT conda recipe, so if you need full control then you'll still want to build from source.
There was some discussion about Python wheels (#191). While I think a PyPi wheel would be still be a useful thing to have, complex dependencies involving non-Python projects quickly become untenable with wheels. It would be hard to put IPOPT in a wheel without some complicated CI work; with conda, it all comes together easily.
There is one hack in this recipe, and that is related to the dependence on the
mdolab-baseclasses
package. The ideal solution would be to havemdolab-baseclasses
available as a conda package, and to specify that as a run dependency of this package. However, that conda package doesn't exist yet. In the recipe I have embedded the source ofmdolab-baseclasses
, pinned to the1.5.2
tag. This can be fixed if/when it is available as a conda package.EDIT:
It probably makes sense to just submit this to https://github.com/conda-forge/staged-recipes, so consider this PR a demonstration. Somebody affiliated with mdolab should probably be the maintainer of that recipe. I can provide some support if needed (I would be able to open the PRs on staged-recipes for both mdolab-baseclasses and this project).
Type of change
What types of change is it?
Select the appropriate type(s) that describe this PR
Testing
In order to build the package, run this from the top level of the repo.
You will need conda and conda-build installed. This will build the package and run tests.
To install the conda package, into the active conda environment:
Checklist
Put an
x
in the boxes that apply.flake8
andblack
to make sure the code adheres to PEP-8 and is consistently formatted