I would think you need a longer name then just JSON that make the meaning clear.
Given that its for default environment then name the variable after its use not its encoding like: PYTHON_PACKAGING_DEFAULT_ENVRONMENT?
I’m not massively enthusiastic about the idea of an environment variable containing a JSON value. My main objections are usability and global impact.
The usability issue is that setting such a variable is annoying - getting the quoting of a JSON value correct is really fiddly, especially of you’re working in a shell you’re not familiar with. Also, Windows doesn’t have the “temporary environment variable” feature from Unix of ENV_VAR=xxx cmd, so an environment variable that affects a single command is much harder to use.
As far as global impact is concerned, I don’t like the idea that setting something in your environment can change the behaviour of any tool that uses packaging, even those you didn’t realise used it. I can easily imagine bug reports along the lines of “pip didn’t install my dependency”, which turn out to be because the user set a different environment via a variable they’d forgotten. Such “action at a distance” makes for difficult-to-track bugs.
Having said this, I am in favour of having an API in packaging that can be used to configure the default environment, so that there’s a way for applications like pip to change it without needing to pass an explicit environment to every call that evaluates a marker.
Yeah, I’d vote for using the environment variable to point at a JSON file containing the info (and possibly there’s alignment here with PEP 739?).
I would also very much like a way to override the platform tag that packaging chooses for the current system. I’d love to be able to embed a configuration file in a Python environment that says “instead of win32, pretend this is my_special_platform” (and then point at a private package index to get perfectly matched custom builds). If you’re going to go for a big change here, please keep going
Yes this is a much better idea and I would also prefer it!
I don’t have time for that and I basically know nothing about the pip code base. Also, I would like more feedback here before considering this controversial
As a maintainer of packaging I don’t love the idea. This feels like a hack to work around other tools that don’t let you specify the environment details explicitly. That function (which we are working on documenting) just gives you the running interpreter’s details, not the way to get arbitrary details of another interpreter.
I’m not quite seeing why packaging is the expected coordination point of passing around data. Isn’t that what function arguments or instance attributes are for in your code?
Not really because now we are just a data store at some module scope that anyone could have done themselves. Toss in that we would then have to manage threaded access, etc. and it seems like an increase in scope for the package (I don’t think we have persistent state anywhere right now, even when people complain about performance and ask for it to work around pip).
But I also like functional programming, so passing state around doesn’t bother me.
You can also see if @pradyunsg disagrees and/or try to sneak it in while I’m out in April.
This is why an environment variable or config file into packaging makes more sense than pushing it out to every tool - you only need to pick up the user-provided setting once, and it becomes the global constant, rather than the code it currently has to calculate the value from ambient information.
Not tried as an interactive commands. Cmd.exe is hard to use outside of batch files… To really see scary stuff have a read of for/? to see what the enterprising nerd can do in cmd.
