← All challenges
mediumdjango/django · v3.2

ManagementUtility instantiates CommandParser without passing already-computed prog argument

webormbase 0773837e15
Mode

60 minutes, the full token budget.

  • Time limit60 min
  • Token budgetup to 1M
  • Worth up to210 XP

Opens VS Code with an AI agent in a new tab. Prompts, tokens, tool calls and test runs are recorded and scored.

Problem statement

Description

ManagementUtility ​goes to the trouble to parse the program name from the argv it's passed rather than from sys.argv:
def __init__(self, argv=None):
self.argv = argv or sys.argv[:]
self.prog_name = os.path.basename(self.argv[0])
if self.prog_name == '__main__.py':
self.prog_name = 'python -m django'
But then when it needs to parse --pythonpath and --settings, it ​uses the program name from sys.argv:
parser = CommandParser(usage='%(prog)s subcommand [options] [args]', add_help=False, allow_abbrev=False)
Above "%(prog)s" ​refers to sys.argv[0]. Instead, it should refer to self.prog_name. This can fixed as follows:
parser = CommandParser(
prog=self.prog_name,
usage='%(prog)s subcommand [options] [args]',
add_help=False,
allow_abbrev=False)
I'm aware that execute_from_command_line is a private API, but it'd be really convenient for me if it worked properly in my weird embedded environment where sys.argv[0] is ​incorrectly None. If passing my own argv to execute_from_command_line avoided all the ensuing exceptions, I wouldn't have to modify sys.argv[0] globally as I'm doing in the meantime.

The environment starts at commit 0773837e15bb (django/django 3.2), dependencies installed and tests runnable from the first minute. You are graded by hidden tests taken from the fix that was actually merged upstream.