Discouraging overly complex Pipfile definitions about pipfile

[ncoghlan]

Just illustrating one of the main reasons this approach counts as a "heavy handed runtime style hint" rather than an enforced security boundary:

>>> exec("print(dir())", {})
['__builtins__']
>>> code = """\
... for cls in __builtins__.__class__.mro()[-1].__subclasses__():
...         maybe_real_builtins = None
...         for name, attr in cls.__dict__.items():
...             try:
...                 maybe_real_builtins = attr.__globals__["__builtins__"]
...             except:
...                 continue
...             if maybe_real_builtins:
...                 print = maybe_real_builtins["print"]
...                 len = maybe_real_builtins["len"]
...                 print(len(maybe_real_builtins))
...                 break
...         if maybe_real_builtins:
...             break
... """
>>> limited_namespace = dict(__builtins__=None)
>>> exec(code, limited_namespace)
150

When you call exec, if you don't specify a builtin namespace, then Python automatically supplies the default one. However, if you do specify one (or explicitly set it to None), then that can still be used as a way of getting runtime access to object (purely via attribute accesses), which in turn grants access to all its subclasses, one of which will inevitably have a method implemented in Python (e.g. the import machinery), which will grant access to that module's globals, and hence to the real builtins.

However, this also shows that programmatically blocking access to the standard builtins isn't especially trivial to work around, so the dozen lines needed to do so provides a really strong hint to say "If you think you need to be doing this, Pipfile probably isn't the right tool for the task at hand"

[takluyver]

Reading the README, with group('development'): came as a doubly unpleasant surprise:

• I don't like specifying metadata in executable files in general. #8 gives one reason why not - it's very hard to reliably modify scripts programmatically.
• If we do use an executable script, I don't like the use of context managers as a way to group statements. Rather than functions that modify some invisible global state, why not build up global state visibly, e.g.:

requirements.extras['development'] = [
    package('nose'),
]

I like @ncoghlan's idea of strongly discouraging overly complex definitions, but I worry that anything that looks vaguely like a security boundary will lead people to trust these files inappropriately. It disguises execution as 'just parse this file'. Also, if you all but disallow code reuse through import, having an executable file doesn't seem so useful.

[ncoghlan]

As noted in #10 (comment) I'm now favouring resolving the imperative-vs-declarative question by offering an imperative Pipfile.in (that provides the full flexibility of normal Python code) that is combined with an automation-friendly declarative Pipfile format (where regeneration from Pipfile.in only modifies entries that were created from Pipfile.in in the first place).

That kind of approach should provide all of the advantages of both the imperative and declarative models, while the restrictive approach I suggest here would mainly leave us with the disadvantages of both models.

[pradyunsg]

@ncoghlan What are your thoughts on this now, given that #10 is resolved and #47 merged?

[ncoghlan]

The switch to a declarative file format resolves this concern, so closing the issue.