Dave Hirschfeld

I see creating extra packages as more of a work-around. There's a lot more boilerplate and it forces the user to deal with (publish) multiple binary artefacts. IMO, it would...

> I think the multi-packages / multi-output way would be by far more backward compatible. I am suggesting we break backward compat here, but it might just be the time...

> we need different repodata.json if i am not mistaken. Yeah, I think it will require a change to the `repodata.json` schema which would likely make it uninstallable by conda...

Doing 1 correctly is slightly tricky and very verbose to do manually (particularly for multiple variables). To do it correctly you want to save the original value on activate and...

Also, I imagine most activate/deactivate scripts only work with `bash`. Automating this process would let you use [`multisheller`](https://github.com/mamba-org/multisheller) to ensure `conda` packages worked for all shells.

> *one approach is https://github.com/mamba-org/multisheller* Yep - my thoughts exactly! 😄 ...it would just be nice if you could somehow automate the generation of the activate/deactivate scripts - e.g. ```yaml...

Anyway, just something I've been pondering so I thought I'd write it up for reference. Prompted by having to maintain 6 env vars and 2 path entries for 3 different...

> This has been used in the community, e.g. in this recipe Awesome, thanks for the ref! That'll be a huge help in figuring out how to port to `multisheller`!

Is there a reason to use `load_setup_py_data` other than setting the version? If it's just for that, there may be better solutions. As a general-purpose solution, `load_setup_py_data` has a critical...

> Ideally instead of reading a setup.py, one would specify dependencies in a `toml` file or similar static metadata file and generate the `boa` and `pypi` "recipes" from that. It...