4 ms·

How do you manage project dependencies? Say, a certain Java/Python version and maybe a running Postgres?

llimllib 5y ago
Not OP, but I have a similar setup and I use asdf or javaenv or pyenv or docker
handrous 5y ago
Databases and other 3rd-party daemons go in Docker because I can install the same version with the same tools pretty much anywhere. Even if it's not being deployed with Docker, the docker-compose file documents exactly the version and config the project expects, and is guaranteed to be correct assuming everyone developing uses it. This also means it's trivial to run several versions, and to add/remove/update/start/stop them independently, including any data or "cruft" files. If Docker were to vanish, the answer would become Vagrant running some very common and stable Linux distro with either a config shell-script or ansible yaml, for similar reasons. Documentation, consistency, and isolation. Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language. [EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.

Not OP, but I have a similar setup and I use asdf or javaenv or pyenv or docker

Databases and other 3rd-party daemons go in Docker because I can install the same version with the same tools pretty much anywhere. Even if it's not being deployed with Docker, the docker-compose file documents exactly the version and config the project expects, and is guaranteed to be correct assuming everyone developing uses it. This also means it's trivial to run several versions, and to add/remove/update/start/stop them independently, including any data or "cruft" files. If Docker were to vanish, the answer would become Vagrant running some very common and stable Linux distro with either a config shell-script or ansible yaml, for similar reasons. Documentation, consistency, and isolation. Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language. [EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.