201–210 of 241 posts
Earlier quoted context omitted.
> and is there maybe a way to come up with a unified language dependency manger? For interpreter/compiler version management you can use asdf [0]. It works for all popular programming languages. You can use it to replace tools such as pyenv, nvm, gvm, etc. [0]: https://asdf-vm.com/#/
There is no link to asdf ( "[0]" ) in your comment
If you're going to be using pyenv + poetry you should be aware of #571 that causes issues with activating the virtualenv https://github.com/sdispater/poetry/issues/571 the OP himself has a fix for this in his own dotfiles repo: https://github.com/jacobian/dotfiles/commit/e7889c5954daacfe...
(Though, how'd you find that? Mildly creepy that you know more about my dotfiles than I do!)
Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…
> Although Docker meets all these requirements, I don't really like using it. I find it slow, frustrating, and overkill for my purposes. How so? I've been using Docker for development for years now and haven't experienced this EXCEPT with some slowness I experienced with Docker Compose upon upgrading to MacOS Catalina (which turned out to be bug with PyInstaller, not Docker or Docker Compose). This is on a Mac, btw;…
My experience has been that it's significantly more effort to meet my requirements with Docker, and that I spend a _lot_ of time waiting on Docker builds, or trying to debug finicky issues in my Dockerfile/docker-compose setup.
I'm sure all of these things have fixes -- of course they do! But I find the toolset challenging, and the documentation difficult to follow. I'd love to learn what I'm missing, but I also need to balance that against Getting Shit Done.
Earlier quoted context omitted.
It's kind of shocking to hear these two quoted as "different than most" requirements – as a Ruby developer, this sounds like exactly a thing that any engineer supporting production systems would need routinely. RVM and bundler are standard developer tools and I would never question the need for supporting multiple versions on the same machine, unless in a very well-defined scenario where RVM was unneeded (like in a c…
I think contemporary best practices start with the production environment and work backwards towards creating a development environment as close to the production environment as possible. These days, most productions environments are effectively isolated containers. If your production environment is a container, you probably should develop in a container as well. In that case you don't need much tooling for isolating…
I'm a developer that supports multiple production applications, and I frequently need to make my development environment as similar to production as possible in order to reproduce a production issue for debugging purposes. I depend on that isolation to be able to do this. My work environment is such that I'm not generally permitted to use containers in production (yet). So it stands to reason through your argument that perhaps I shouldn't use them in development either. It sounds like if I were using Python as well instead of Ruby, I'd be having a much harder time.
Honestly, if I could use containers in dev and prod I would, I truly do believe the grass is greener ;) but I would not sacrifice this marvelous isolation tech, in fact I'd prefer to take RVM with me into docker-land so that I can A-B test Ruby versions within the same container image, and be guaranteed that all my cluster's worker nodes will not have to take extraordinary measures and carry both images in order to ensure the application can boot without a download delay, whenever we have to revert the canary (or whatever other minor potentially reversible lifecycle event would normally trigger a node to need to download a new, expensive base set of image layers all over again.)
This works really well: https://github.com/ms-ati/docker-rvm
It feels pretty comfy to effectively be on an island and far away from the hustle and bustle of the industrial Python tooling.
Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…
I never had any issue myself, but I guess that is because I use the standard tools: python3 -m venv /tmp/foo /tmp/foo/bin/pip -U pip wheel /tmp/foo/bin/pip -r requirements.txt I understand some might not like it, but really, it's simple and it works.
Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…
Earlier quoted context omitted.
You should try Dockerizing your project. Then other people just have to type docker run and it’ll work everywhere.
Well in sceintific projects you are working in HPC platforms which docker doesn't exists and there are many reasons for it (it is not just technical).