Initial comments

[chrisdembia]

@kidzik it's awesome that you've created this conda package. Here are my comments (mostly questions). No need to respond to them now; we can discuss in person, etc.

1. Should we depend on the existing Simbody package?
2. I think it's fine to not create a separate package for BTK.
3. You can use OPENSIM_COPY_DEPENDENCIES to avoid needing to copy BTK/Simbody manually.
4. We should chat about what installation layout makes sense for conda; we have two options (OPENSIM_INSTALL_UNIX_FHS=on/off), especially on Windows.
5. We should document this installation option in opensim-core's README, and eventually also document it on Confluence.
6. Should we install OpenSim's command-line tool, opensim-cmd?
7. Should simbody-visualizer should be installed in libexec/simbody or bin? It's somewhat built into the Simbody libraries that its location relative to the Simbody libraries does not change.
8. We should run the python tests after the build is complete.
9. Should we support other distribution mechanisms, namely binary wheels on PyPI?
10. Should we continue distributing the python build in the OpenSim GUI distribution on SimTK.org?
11. Should the conda package also install examples? Is this typical with conda package? How do conda users typically obtain examples?
12. What's the process for getting the package into the conda-forge channel, and when should we start that process?
13. Does conda have guidelines for python packages that contain C/C++ libraries? Would it ever make sense to have separate packages for the C++ library and the python package?
14. Do we expect C++ users to be able to use the C++ libraries in the package? That is, are the CMake config files and the headers installed properly?

cc @moorepants

[moorepants]

Some comments

Should we depend on the existing Simbody package?

You can set this up however you like, i.e. package for every dependency or all dependencies packaged together. But if you would like to get this on conda forge, which I recommend, you'll need to make a conda package for each dependency (in general).

I think it's fine to not create a separate package for BTK.

If for conda forge, this should definitely be a different package.

You can use OPENSIM_COPY_DEPENDENCIES to avoid needing to copy BTK/Simbody manually.
We should chat about what installation layout makes sense for conda; we have two options (OPENSIM_INSTALL_UNIX_FHS=on/off), especially on Windows.
We should document this installation option in opensim-core's README, and eventually also document it on Confluence.
Should we install OpenSim's command-line tool, opensim-cmd?

I think so.

Should simbody-visualizer should be installed in libexec/simbody or bin? It's somewhat built into the Simbody libraries that its location relative to the Simbody libraries does not change.

The conda forge simbody package puts it in libexec.

We should run the python tests after the build is complete.
Should we support other distribution mechanisms, namely binary wheels on PyPI?

This may be possible now that the wheel infrastructure is more mature but my hunch is that this would be be more work than getting a conda package going. It also may be a little stretch call opensim a python package, and thus appropriate to have in PyPi. I've heard some talk about how you may be able to convert wheels to conda packages and vice versa. Never tried it though.

Should we continue distributing the python build in the OpenSim GUI distribution on SimTK.org?
Should the conda package also install examples? Is this typical with conda package? How do conda users typically obtain examples?

Good question. I don't think anything is customary yet. If you want to include examples you can put them in /usr/local/share for example. I did this with the Simbody one, I believe. You can add the docs too. I think most people get these things from the internet these days though.

What's the process for getting the package into the conda-forge channel, and when should we start that process?

I recommend starting it now. You can submit a PR to the staged-recipes repo. I already have one there for Opensim 3.0 which has stalled. Feel free to take it over. There will be more work to do to get it conda forge ready. They also typically want official releases, but I think you can setup a beta/alpha/rc channel (see matplotlib's example of this).

Does conda have guidelines for python packages that contain C/C++ libraries? Would it ever make sense to have separate packages for the C++ library and the python package?

My plan was to make separate packages like:

• liibopensim (on C++)
• opensim (C++ and Gui if that ever get's open sourced)
• python-opensim (python wrappers)

But you could just have opensim and it has all of the above and just have one package. Symengine is a C++ lib with python, ruby, julia, etc wrappers and they have symengine and python-symengine, i.e. pure C++ and the python wrappers.

Do we expect C++ users to be able to use the C++ libraries in the package? That is, are the CMake config files and the headers installed properly?

You'll need to ensure this. I think it would be very nice to have all this done properly. I'm don't think I have it quite right with the simbody package.

[moorepants]

Note that ipopt, mumps, sundials, symengine don't prepend lib even though they are C/C++ libs.

[moorepants]

Probably worth reading too: conda-forge/staged-recipes#2136

[chrisdembia]

Thanks @moorepants; that information is very helpful.

[moorepants]

Here is an example of a C++ lib with python bindings being built into a wheel for PyPi:

https://blog.kitware.com/itk-is-on-pypi-pip-install-itk-is-here/

https://blog.kitware.com/itk-python-wheels/

Could be helpful to see how they do it.

[chrisdembia]

Thanks for those links. I found their scripts for creating the wheels:
https://github.com/InsightSoftwareConsortium/ITKPythonPackage/tree/master/scripts

[kidzik]

Thanks, Chris, I totally agree with the comments and @moorepants answers! The current version is clearly hacky to just have it up and running, but making it clean won't be difficult.

[davidpagnon]

Hi @kidzik and @chrisdembia,

I'm quite late to the party, but I'm trying to submit Pose2Sim and Sports2D to conda-forge, and the only dependency that is preventing me from doing so is OpenSim. And I'm sure having OpenSim on conda-forge would make it easier for other users who might run into python/numpy dependency issues.

Do you feel like it would be very tricky to get it accepted? Or just knowing that someone is interested would be enough to give you this little push?

Thanks for your consideration!

[moorepants]

For reference there are some prior attempts:

• Add opensim recipe to conda forge conda-forge/staged-recipes#18133
• Opensim conda01 conda-forge/staged-recipes#17971
• Adding opensim package conda-forge/staged-recipes#11894
• OpenSim init recipe conda-forge/staged-recipes#4693
• [WIP] Added a recipe to build Opensim 3.3. conda-forge/staged-recipes#2136

The primary issue is likely that Conda Forge requires dependencies to be unbundled and dynamic linking to dependencies. They have some policy exceptions, but you'd have to investigate with the Conda Forge maintainers.

[chrisdembia]

@aymanhab @carmichaelong @nickbianco are more likely to get this done

[davidpagnon]

Thanks, I had not seen the latest attempts! Not sure how much time I can dedicate to it, but I'm willing to participate if needed.

[traversaro]

Feel free to ping me in the related staged-recipes PRs, I am a reviewer there and also quite interested in having opensim in conda-forge as it is used in my organization.