On 6 May 2016 at 06:30, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Usually that enforcement is handled by making the configuration declarative - it's in some passive format like an ini file or JSON, and if it gets too repetitive then you introduce a config generator, rather than making the format itself more sophisticated.
OK -- that's more or less my thought -- if it's python that gets run, then you've got your config generator built in -- why not?
The immediate reason is because Python allows imports, and if imports are permitted in the config script, people will use them, and if they're not permitted, they'll complain about their absence. The "Python-with-imports" case is the status quo with setup.py, and we already know that's a pain because you need to set up an environment that already has the right dependencies installed to enable your module level imports in order to run the script and find out what dependencies you need to install to let you run the script in the first place. The "Python-without-imports" approach would just be confusing - while it would avoid the dependency bootstrapping problem, it would only be kinda-sorta-Python rather than actual Python. So rather than saying "the bootstrapping dependency declaration file is Python-but-not-really", it's easier to say "it's an ini-file format that can be parsed with the configparser module" or "it's JSON" (I'm ruling out any options that don't have a stdlib parser in Python 2.7) The "future benefit" reason is that it's a lot easier to be confident that reading a config file from an uploaded artifact isn't going to compromise a web service, so a future version of PyPI can readily pull information out of the config file and republish it via an API. Once you have that kind of information available via an API, you can resolve it before downloading *anything* (which is especially useful when your goal is dependency graph analysis rather than downloading the whole of PyPI and running a Python script from every package you downloaded). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia