Is it better to invoke hatch as a subprocess or programmatically from within a hatch command itself?

[Midnighter]

To add some context to my question: I have a cookiecutter template that I want to test. So the tests instantiate the template and create a project. Then, I run all the tests that come with the template in that project. At the moment, I do this by running tox as a subprocess in the test case itself.

I'm in the process of replacing tox with hatch environments which got me wondering if I can also call, for example, hatch test, programmatically from within the test case. Or maybe that is a bad idea because the nested hatch calls would be confusing configuration/environment wise? I appreciate any insights.

[Midnighter]

I got it somewhat working, i.e., it seems fine on POSIX but fails on Windows. See my cookiecutter project https://github.com/Midnighter/cookiecutter-python-package and failing Windows tests https://github.com/Midnighter/cookiecutter-python-package/actions/runs/9720089690/job/26830982226

[Midnighter]

In that last run, the entire pipeline finished on POSIX within 20-50 s, whereas on Windows it took 15 minutes.

[Midnighter]

Got a little further, I inspected the subprocess output and on POSIX found the following, which tells me that probably the given command is not well formatted. I think, in such cases hatch should exit with code 2 and not 0. That would clearly indicate that something went wrong.

Usage: hatch [OPTIONS] COMMAND [ARGS]...

   _   _       _       _
  | | | |     | |     | |
  | |_| | __ _| |_ ___| |__
  |  _  |/ _` | __/ __| '_ \
  | | | | (_| | || (__| | | |
  \_| |_/\__,_|\__\___|_| |_|

Options:
  -e, --env TEXT                  The name of the environment to use [env var: `HATCH_ENV`]
  -p, --project TEXT              The name of the project to work on [env var: `HATCH_PROJECT`]
  -v, --verbose                   Increase verbosity (can be used additively) [env var: `HATCH_VERBOSE`]
  -q, --quiet                     Decrease verbosity (can be used additively) [env var: `HATCH_QUIET`]
  --color / --no-color            Whether or not to display colored output (default is auto-detection) [env vars:
                                  `FORCE_COLOR`/`NO_COLOR`]
  --interactive / --no-interactive
                                  Whether or not to allow features like prompts and progress bars (default is auto-
                                  detection) [env var: `HATCH_INTERACTIVE`]
  --data-dir TEXT                 The path to a custom directory used to persist data [env var: `HATCH_DATA_DIR`]
  --cache-dir TEXT                The path to a custom directory used to cache data [env var: `HATCH_CACHE_DIR`]
  --config TEXT                   The path to a custom config file to use [env var: `HATCH_CONFIG`]
  --version                       Show the version and exit.
  -h, --help                      Show this message and exit.

Commands:
  build    Build a project
  clean    Remove build artifacts
  config   Manage the config file
  dep      Manage environment dependencies
  env      Manage project environments
  fmt      Format and lint source code
  new      Create or initialize a project
  project  View project information
  publish  Publish build artifacts
  python   Manage Python installations
  run      Run commands within project environments
  self     Manage Hatch
  shell    Enter a shell within a project's environment
  status   Show information about the current environment
  test     Run tests
  version  View or set a project's version

[ofek]

what's the command?

[ofek]

oh on non-Windows systems when using shell=True you must always pass the command as a string, Windows in all cases works as a list of strings

[Midnighter]

And all solved, as usual the problem was between chair and screen. Thank you for indulging me.

[ofek]

Glad it's working now, happy to help!

[Midnighter]

And yes, these details messed it up for me. Windows works in all cases with a list, because it is in any case converted to a string. Details can be found in https://docs.python.org/3/library/subprocess.html#popen-constructor

On Windows, if args is a sequence, it will be converted to a string in a manner described in Converting an argument sequence to a string on Windows. This is because the underlying CreateProcess() operates on strings.

The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.

On POSIX with shell=True, the shell defaults to /bin/sh. If args is a string, the string specifies the command to execute through the shell. This means that the string must be formatted exactly as it would be when typed at the shell prompt. This includes, for example, quoting or backslash escaping filenames with spaces in them. If args is a sequence, the first item specifies the command string, and any additional items will be treated as additional arguments to the shell itself. That is to say, Popen does the equivalent of:

Popen(['/bin/sh', '-c', args[0], args[1], ...])