That's how Bundler does it in the Ruby world, and I haven't really seen any logic in Gemfiles. Pretty much everyone sticks to the DSL. Of course there's someone who did that, but I personally haven't seen that, ever.

> eval ... makes me shudder

Why do you prefer using ``pip`` despite ``pip install`` using the package's ``setup.py`` (and therefore is an eval)?

Further, if you're using a package manager, I expect you won't be combing through the source to check for malicious code anyway.

For the non-install case, like when you're running a package index, having to eval the dependency specifying is horrible.

This is also why wheels (the new python package format) use a static file instead of setup.py. The Python ecosystem has been trying to get off of "just eval setup.py" for years.

I'm not sure why avoiding arbitrary code execution during install is important when you're going to do arbitrary code execution shortly after. What else is the purpose of installing a package?

> For the non-install case, like when you're running a package index

You have just ignored the point that your parent point was making. It's not the install case that they were complaining about.

True. It's surprising to optimize for such a rare kind of user.

trying to not run arbitrary code on the enterprise network is prudent.

But that'd happen anyway when the installed package gets executed.

My concern is more about fragile code than malicious code. I've had many experiences of packages where "python setup.py install" wouldn't work locally, and then I looked inside setup.py, and was confronted with a wall of conditional statements or dependencies on system libraries. Dependency declaration can, and should, be much simpler and more bulletproof than that.

That's the benefit of shipping binaries, but the downside is they're harder to patch / swap dependencies. Trade-offs, always.

Wasn't wheels suppose to fix that? IIRC you can't have executable code in a wheel unlike the setup.py.