d@nny "disc@" mcClanahan<p><span class="h-card" translate="no"><a href="https://lingo.lol/@fay" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>fay</span></a></span> so spack also has a pybind11 package maintained by axel huebl and there is a lot of work to make native python bindings work right automatically (spack uses this kind of support in order to call the c++ clingo logic solver from python, although it does not use pybind11 there). the main docsite is <a href="https://spack.readthedocs.io/en/latest/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">spack.readthedocs.io/en/latest</span><span class="invisible">/</span></a> (also see tutorial at <a href="https://spack-tutorial.readthedocs.io/en/latest/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">spack-tutorial.readthedocs.io/</span><span class="invisible">en/latest/</span></a>), but the packages you'll want to install are <code>py-pybind11</code> and <code>py-torch</code> for this. spack will produce the same kind of library output that you would see in /usr/lib and /usr/include if you installed as root, but without modifying any global state (spack itself is typically used via git repo). in case you're interested, the <code>py-pybind11</code> package recipe is located here: <a href="https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/py-pybind11/package.py" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/spack/spack/blob/de</span><span class="invisible">velop/var/spack/repos/builtin/packages/py-pybind11/package.py</span></a>.</p><p>while you <em>could</em> make a spack package recipe for your own code, that's generally more useful if you want to distribute it as its own library/binary. for my <a href="https://github.com/spack/spack/issues/41960" rel="nofollow noopener" target="_blank">cargo interface</a>, what i do is essentially:</p><ul><li><code>spack install py-torch py-pybind11</code> to install packages (spack has a <a href="https://spack.readthedocs.io/en/latest/basic_usage.html#specs-dependencies" rel="nofollow noopener" target="_blank">"spec" interface</a> for specifying dependencies)</li><li><code>spack load py-torch py-pybind11</code> => this will make those packages available in the current shell (so if you run <code>python</code>, those packages should be available)</li><li><code>spack find -l -v -p ...</code> to find where spack installed them (there are other ways to do this, but this is how i plug it into cargo. typically, the <code>/lib</code>, <code>/include</code>, etc subdirectories of the prefix returned by <code>spack find -p</code> will be populated for c/c++ packages)</li></ul><p>spack also has a <code>dev-build</code> command which is useful if you make your own package recipe, but i believe most spack users are not developing package recipes and are instead just using it to install stuff, and it is extremely important to me personally that spack is usable without drinking any kool-aid.</p><p>spack also has a python scripting interface which i use in my cargo wrapper and which is capable of everything the main spack tool is, but the CLI is often quite capable by itself, and completions are provided for zsh, bash, fish, and some other shells.</p><p>i am going to leave this here as a reference in case it's useful. i think spack separating the build system from the package manager is extremely important and necessary--it means codebases don't need to be patched to support spack, and other build systems/package managers can consume spack as a subprocess: i don't know a single other tool, let alone a c/c++ package manager, that accepts being used silently as a subprocess.</p><p>i would be interested in providing further specific assistance but i understand that switching infrastructure is not easy to do, so please feel free to ignore this as well. i just care quite a lot about fixing builds for scientists like you without pushing some form of vendor lock-in and i have latched onto spack because i think it's the closest thing to what i want.</p>