I don't think the lockfile is a big problem (and I don't have enough experience with lockfile-based systems), but if you already have some other file that can serve the same purpose, isn't that nicer than having two? It also means you don't have to be confused about whether lockfiles should be committed to version control (apparently the answer is "not always", which is counter-intuitive to me).

When are you not supposed to commit a lockfile? I think the norm is to commit it.

You're supposed to commit it for applications, but omit it for libraries. Libraries declare the versions they're compatible with but they don't lock to specific releases.

In at least some packaging systems, committing the lock file for a library is useful so that the library maintainers use the same versions. (It's ignored by users of the library.)

I had some experience with plone (and zope) - big, early python projects that formed a lot of the basis for package management and infrastructure for python.

The "known good set" of packages as used by buildout for any given plone version were not really easy to work with.

See eg:

https://docs.plone.org/4/en/manage/troubleshooting/buildout....

Which points to things like: http://dist.plone.org/release/3.3.5/versions.cfg

Which aren't that much worse/better than a gemfile.lock for a rails project, I guess.

Now, I guess the better answer is to have smaller projects, with different interfaces (eg: don't give all modulles/parts access to your zodb object database, have a ome json/rest interfaces etc).

But apparently there are still many "big systems" being built.