You lose flexibility if you can't parse or modify the file with a known parser (TOML, JSON)

And if you read the link, you'll see discussion of this.

1. The executable format is used to create and output a .lock file, which is JSON and is the thing actually used to reproduce the environment (i.e., the .lock file is what you'd use when deploying the full environment).

2. TOML and other formats are being considered; right now something that parses to a Python AST is used for convenience to work out the API.

Of course, nobody commenting in this thread actually read any of that, so it's just people reiterating "I can't believe they didn't consider this thing they considered!"

Why are you replying with this to me? I'm not saying anything contradictory to any of that.

You should parse the file by running it.

I'd expect any developer worth their salt to know why that's a bad idea - or are we still parsing json using eval()?

That sounds like a terrible idea - especially if you don't know if you can trust the source of the file.

Installation files by default are run. If you have a normal Python module sitting on PyPi, and install it it may run a setup.py which could potentially do anything that your currently active user is allowed to do.

Adding custom programming logic into the requirements' file isn't really an issue, when setup.py could already grab a C compiler and start binding in system libraries into its package.

You're missing the forest for the trees. My point was that you're losing flexibility when you're not able to parse/generate a data-driven file using a well-known data format.

And unless you're using a homoiconic format, code is not (easily) parsable as data.