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.