| I'm not sure why you think conda doesn't support that. You might want to look at [0] specifically the section titled "Building identical conda environments", and at the documentation for "conda list --export --md5" and "conda list --explicit" (and if you don't use pip also "conda list --canonical") which all do exactly that, and which can all be fed back to start a new environment. Also "conda env export", which adds some more documentation; In fact, all defaults list explicit versions of packages. The only way you can list installed packages without it is "conda env export --from-history", which will reproduce the non-version-annotated list. So, yes, you don't have a "requirements.txt" and a specific lockfile maintained on disk; instead, conda manages it, and if you want it in source control (and you likely do), you need to make sure your local pre-commit hook runs the export. But everything is indeed reproducible, without any additional package needed. > apt install gcc:4:4.9.2-2 Ok, so your ci (and everyone) must be root / fakeroot; and you somehow have to manage that outside your requirements.txt and lockfile (e.g. in a pre-commit or post-checkout hook). And you can't have more than one at the same time on the same system (so your ci must have different containers/vms to build two executables with conflicting requirements, even if they are part of the same project). And you can't do it on Windows or Mac at all (whether root or brew user or whatever). From every possible aspect, Conda is much, much more suited for reproducible and well defined builds. It does it differently than managers using lockfiles; But it definitely does it, and more completely. p.s. conda also has "conda list --revision" which shows you the entire history of version updates. Very useful for troubleshooting, even if not strictly required. [0] https://docs.conda.io/projects/conda/en/latest/user-guide/ta... |