06:00 <cyrozap> scientes: You can make and enter a virtualenv with just `python -m venv .env && source .env/bin/activate`. It's pretty standard that, for most projects, you'll need to initialize a virtualenv to install their dependencies into before using them. Otherwise, you can get into dependency hell with projects that require conflicting versions of the same module.

06:04 <scientes> cyrozap, except that modules cannot then have their own virtualenvs, so you are still in dependency hell.

06:05 <cyrozap> zyp: Regarding keeping dependencies as submodules: You can also add the git URL of the dependency to your requirements.txt and add the commit hash to the end, so the dep gets installed with all the others for your project, and you won't have to deal with the submodule separately.

06:07 <cyrozap> scientes: Oh, yeah, generally the "top-level" project is responsible for keeping track of dependency versions, hence the need for "pip freeze".

06:08 <scientes> in that case virtualenv creates problems, rather than solving them

06:08 <scientes> this is the same problem that causes Debian ti forbid embedded copies of programs

06:09 <scientes> and this is a dynamic language, so dependency problems are *theoretically* easier

06:15 <cyrozap> Yeah, Python's dependency management definitely has issues, but in my experience virtualenvs paper over those issues nicely.

06:17 <cyrozap> Emphasis on "paper over" of course :P

06:18 <cyrozap> Dep management seems to be a recurring problem in programming languages.

06:20 <cyrozap> C is either "What are dependencies?" or "Let your distro's package manager handle it--hope you don't need any bleeding-edge code."

06:21 <cyrozap> C++ is like C, but with more "Copy the code into your repo because the version we need is 3 major versions ahead of the one in most distros' repositories."

06:24 <cyrozap> Go used to be "just don't ever break anything" and "if things are getting broken (which they totally never ever would because why would anyone do that), just copy the code into your repo in this special directory that you can't rename (because why would anyone do that, either)", but now it's "send the list of dependencies to Google so they can cache them for you... and also do analytics on what

06:25 <cyrozap> everyone's using".

06:29 <cyrozap> Rust seems to be heading in the right direction, but there's a huge monoculture around cargo + crates.io and it's caused some problems for build systems like Meson.

06:31 <implr> I fear that rust is heading too far into haskell/hackage's direction

06:31 <implr> with hundreds of small packages with tons of diamonds between them

06:32 <implr> to be fair in both (hs&rust) cases it's somewhat caused by the way the language works (advanced types + compiled)

07:24 <zyp> IME how much a hassle dependency management is is more a matter of how much of a moving target the dependency is than of the language involved

07:27 <zyp> and then there's also the distinction between build time dependencies and runtime dependencies

07:28 <zyp> since embedded projects by their nature pretty much only have build time dependencies, git submodules is a pretty straightforward way of managing them

14:26 <whitequark> python's package management is about to get a whole lot better

14:27 <whitequark> there are several people whose job is to improve pip based on actual user surveys, and that's already bearing fruit