With more languages being used to process data and each coming with its own canonical package mgt; this creates issues for polyglots. There is resistance to work /with/ conda to gain scaling efficiencies. Furthermore, 99% of users will not participate in the relatively easy process of creating a conda package.
The only way this can be managed is for conda-build to programmatically go into each language’s packaging and extract a package def and build recipe. I know this happened for (python) pip packages, R (not sure how comprehensive this is), but Julia isn’t there yet.
OR
each language can just be its own thing but inside a conda environment (where conda could just drive other pkg mgrs).
Otherwise, we’re going to go back to shell scripting to set up environments.
Understood. Unfortunately, most take the path of least resistance when installing packages: pip this, conda that, npm this, apt-get when on linux, curl something | sh, …etc, homebrew on mac. Now take these commands and put them in a dockerfile. This is in addition to getting library authors to get on conda.
10+ years after conda and still most just see it as a way (of multiple) to install packages when it can be just a thin process around established packaging practices.
Well, that’s always going to be the case, until those “native” systems don’t work for someone’s use-case – that’s why conda was created in the first place.
It’s not the people “see it” that way – it’s that that’s what it IS – conda exists because native package managers (notably pip) don’t solve some problems – it is not, and cannot be a “thin process around established packaging practices.”[*]
grayskull and the like can be used to make it easy to make a conda package from another package spec – but it will only work in teh easy and obvious cases – it’s a utility, not the primary process.
A couple of specific issues about the "thin wrapper idea. (using pip as an example)
the names of dependent package may be different between conda and PyPi
pip packages don’t have any data about non-python dependencies
any dependency can be har dto define definitively in the context of other packaging sytems – wht does “libpng” meand to yum, or apt-get or chocolaty, or …
there may be multipel ways to build a package / dependency – e.g. numpy can use a built in BLAS-lite, or another external BLAS – and those can be open source or proprietary, etc.
If you think a tool like that would be useful, then by all means go build one – but that’s not what conda is.
[*] – Yes, it could be a thin wrapper around, e.g. pip for pure python packages – and maybe that’s a feature that could be added as a special case, but it would be just that: a special case.
ya so julia can ‘solve’ for the packages (sticking to the julia community’s way of doing things)…and just give the solution to conda to install. imo, this kind of interaction would be amazing.