Meanwhile when I use Rust all these things are taken care of in cargo. It is part of the language. There is one right way to do things and the way is supported by comfortable tooling, that works so well that you literally don't even consider thinking about anything else.
The way python does dependencies is totally unpythonic. The fact that it is 2021 and this isn't fixed or at least the number one priority of things that need fixing sheds a dark shadow on the whole language – a language that I like to use.
Poetry is good. But it isn't as good as cargo, because it also has to deal with all the legacy cruft. To run code developed with poetry on a non-poetry system you have to figure out all the ways of dealing with envs, paths and such.
Issues like these get me a little fired up, because the collective brainpower wasted on something that should have been elegantly solved in one place is gigantic.
Now I know how to do this, so this is not a problem. My complaint was mostly, that this was a waste of time.
Needless to say, I will only use the distro package manager these days. I know the versions are (probably) compatible, maintainers will usually backport security patches, etc. You get none of that using whatever flavor of the week python package manager.
The distro package managers are probably the best place for that, but bridging the gap between them and the python ecosystem is an obvious challenge.
So for anyone reading this in the future: don't try to use Pyenv to install Conda. Pyenv tries to set up shims for every binary in the Conda env, which will likely break your PATH.
Pyenv supports installing Conda because Anaconda used to be "just" a Python distribution.
They can otherwise coexist without trouble on the same system.
It does this so that it can set up its shim to handle any executable that gets installed in any Pyenv-managed environment.
This is how Pyenv creates the "foobar is not available in your current environment, but is available in x.y.z" message. It's also a much more reliable solution than trying to explicitly whitelist every possible script that might get installed.
The problem is that this was only designed to work for Python executables and scripts installed by Pip. Conda environments can contain a lot more than that; it's not hard to end up with an entire C compiler toolchain in there (possibly even both GCC and LLVM) or even Coreutils.
If Pyenv detects `bin/gcc` in a Conda env, it will set up a system-wide shim for GCC, which no longer passes the `gcc` command along to the OS, but intercepts it, only to inform you that no such command exists in the current env!
So it's not that Pyenv hoses Conda envs. It's that Pyenv can hose PATH if you have it manage a Conda installation, and if that Conda installation ends up with non-Python stuff in `/bin`.
Obviously I don't know what exactly was broken when you tried to set up that application. But this particular adverse interaction bit me at work a few years ago, and ever since then I have insisted that Pyenv should never manage a Conda installation.
I think that's a reasonable policy anyway, in light of the facts that:
1) Conda isn't really a "Python distribution" anymore.
2) The Pyenv installer just runs the opaque Conda installer script and there's basically no way to control the version that gets installed.
3) They are different tools that serve different purposes and it doesn't make sense to have one manage the other anyway.
4) You probably shouldn't use the Python that's installed in the base Conda environment anyway. You need that to run Conda itself, and you want to keep the list of requirements small to make sure that updates can progress cleanly. It's basically the same as any Linux package manager like APT. Except of course, those tools don't generally support "environments" other than chroot.
Tip: in such situations I start looking at the CI scripts in their repositories. Not ideal but gets me through!
I'm not a Python dev; I just needed to run a tool that didn't have any other alternatives.
Meanwhile, I can download scripts written in a range of other languages and just fire 1-2 commands and the thing will work.
With Python? Almost never.
- sudo apt install pip3
- pip3 install --user --upgrade pipenv
(In workdir):
- pipenv install --three package
- pipenv run package --option
Works like a charm and doesn't mess with my system.
Do you have an example of a situation when the two tools had issues? I've been using both for years, and don't remember having any problems.