I had to install a couple of alternative python versions on my dev machine at work and found it was easiest for me to just build from source and `make altinstall` with a custom prefix set. From there I just always work in virtual environments. This doesn't seem to have created any major problems for me, so something like asdf doesn't feel necessary. Is there something serious that I've missed or is this just a case o…
Install Asdf: One Runtime Manager to Rule All Dev Environments
51–60 of 132 posts
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#52Is it just me that never even wants to get to the problems that asdf attempts to solve? That example in the article of managing multiple python 2.7 versions sounds like a horror story.
OP here, although I hoped I took an example that was relatable, it seems it wasn't as relatable as I expected. > Is it just me that never even wants to get to the problems that asdf attempts to solve? You aren't alone, the scenario isn't ideal. However, brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle. You are one cask, formulae or apt package away from needing to do a weekend-…
I've been using python installed using homebrew and haven't found any issues. In homebrew you can install a specific python version like python@3.11 and using venvs avoids most of the issue (I think you can't install packages outside of a venv in python 3.12 or higher).
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#53Earlier quoted context omitted.
Why this over Poetry? asdf handles tools, not really packages. So asdf would install Python and not Python packages.
My experience with Poetry has been mixed the last couple of times I've tried it, it attempts to do way to many things but often failed to do them properly. Determining dependencies and proper packaging and upload to PyPI are the ones which come to mind. asdf.vm together with pipenv is my go-to for Python environment management.
[0] https://pip-tools.readthedocs.io/en/stable/
As for Poetry, it is constantly improving and has gotten very popular. It should not be dismissed, especially for larger projects since its dependency management is so much better than pipenv. This is a good primer: https://diegoquintanav.github.io/poetry-primer.html
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#54Because of the insanity of python versions, paths, wheels etc and tiredness of spending time getting poetry install to work for project X due to also needing a full rust and c++ toolchain for some dependency etc.. .. I run everything for a project in a container. Each project then matches perfectly the container actually used in production, so if it works there, it also works on my machine. I just volume mount the pr…
Development inside a container is still pretty darn miserable though. Nice in theory but not worth it.
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#55Earlier quoted context omitted.
My experience with Poetry has been mixed the last couple of times I've tried it, it attempts to do way to many things but often failed to do them properly. Determining dependencies and proper packaging and upload to PyPI are the ones which come to mind. asdf.vm together with pipenv is my go-to for Python environment management.
pip-tools[0] is all most things need IMO. It’s a great balance of simplicity and utility. [0] https://pip-tools.readthedocs.io/en/stable/ As for Poetry, it is constantly improving and has gotten very popular. It should not be dismissed, especially for larger projects since its dependency management is so much better than pipenv. This is a good primer: https://diegoquintanav.github.io/poetry-primer.html
I think it’s fair to see appeal in poetry, but ultimately the maintainers have created a culture that feels a bit too non-collaborative to outside ideas or use cases beyond what they more narrowly envisage. That said, my perspective may just be tainted by multiple poor experiences interacting with the maintainers.
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#56I've used asdf for years, but recently switched to https://github.com/jdx/mise It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer. See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.
Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#57Earlier quoted context omitted.
Whish there were some CLI to speed up this process actually. Just cd:ing into a folder should pull everything down for you to run iex/irb/node/etc as if it was native but running through the container.
this makes me itchy, pulling the whole internet without looking into your development machine sounds like a very bad idea. It's the equivalent of an IDE's "do you trust this project" but on steroids.
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#58I've used asdf for years, but recently switched to https://github.com/jdx/mise It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer. See: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
Mise/rtx doesn't cut it for us. It's approach is shell-based, so if your programs launch sub-processes, mise won't be applied. So for example Node scripts running in version 18 might npm run a process, which gets launched with the system node.js version. Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied. Mise looks well built & is ve…
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#59Earlier quoted context omitted.
Development inside a container is still pretty darn miserable though. Nice in theory but not worth it.
Dont we have VSCode Dev Containers? That works impressively well
For one, you have to limit yourself to vscode and/or other IDEs with this capability - which ought to be a dealbreaker right there.
But then you still have issues around syncing permissions and paths inside+outside the environment. And that all your other windows have a different view into your project.
That alone is another dealbreaker (which you can bandaid, but...).
And then if you need access to USB devices, well for one I hope you are running linux but even then that is a frigging nightmare. And there is some headache balancing everything above with admin rights etc.
Yes in theory it is perfect. In practice we are not nearly there and you quickly realize the effort to do this well is orders of magnitude more work than just running native.
I still always have a container for continuous integration in a way that you can run it easily on your workstation and can be turned into a devcontainer and/or built manually for small fixes in an old project you haven't used in a long long time. Which is great!
But for your main development? I really tried but it is a nightmare in disguise.
Re: Install Asdf: One Runtime Manager to Rule All Dev Environments
#60Earlier quoted context omitted.
Mise/rtx doesn't cut it for us. It's approach is shell-based, so if your programs launch sub-processes, mise won't be applied. So for example Node scripts running in version 18 might npm run a process, which gets launched with the system node.js version. Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied. Mise looks well built & is ve…
you can use shims with mise
I switched from asdf to mise and everything works fine _if_ you setup shims.