add action input to configure working dir about isort-action HOT 4 OPEN

Have you tried using the requirementsFiles and sortPaths options to specify which requirements should be installed & then restrict import sorting to the relevant subdirectory? e.g.

name: Run isort
on:
  - push

jobs:
  lint-foo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: isort/isort-action@master
        with:
            requirementsFiles: "my-proj/sub-proj-foo/requirements.txt"
            sortPaths: "my-proj/sub-proj-foo"
  lint-bar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: isort/isort-action@master
        with:
            requirementsFiles: "my-proj/sub-proj-bar/requirements.txt"
            sortPaths: "my-proj/sub-proj-bar"

from isort-action.

Ah I glossed over that. That works for some of our packages, others (that need to be published to an internal registry) use a setup.py, so the pip install -r "$file" in bin/install_packages won't quite work. We also run some other steps in this workflow where it'd be convenient to not have the pip install command be bundled with a linting step, but rather done separately with some auth handling for our internal registry. Or is there something else for running, say, a pip install . .[test]?

from isort-action.

did a quick test, I loaded up a virtualenv and did the equivalent of:

(my-venv) $ cd my-proj
(my-venv) $ isort --check --diff --profile=black .
(my-venv) $ cd sub-proj-foo
(my-venv) $ isort --check --diff --profile=black .

and got different results. Keeping the venv constant should basically have the same effect as running bin/install_packages $PYTHON_VERSION sub-proj-foo/requirements.txt right? So then maybe isort itself is finicky about the path?

from isort-action.

We also run some other steps in this workflow where it'd be convenient to not have the pip install command be bundled with a linting step.

Should be totally possible with the current setup. Just exclude the requirementsFiles input and perform whatever setup is required in an earlier step. e.g.

...
jobs:
  lint-foo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: echo "Installed the required dependencies here..."
      - uses: isort/isort-action@master
        with:
            sortPaths: "my-proj/sub-proj-foo"

... and got different results ... So then maybe isort itself is finicky about the path?

Out of curiosity, what were the differences? It would be easier to say definitively if there was a repro you could share.

Note that if each of the subdirectories has its own config file with different isort settings, the plugin would currently require you to override the default for the configuration input. (Current default is --check-only --diff, and you'd need to update it to something like --check-only --diff --settings-file=my-proj/sub-proj-foo/.isort.cfg)

An alternative would be to add support for another option named something like workingDirectory that would update the working directory of the step & all commands would be run from that relative path. (Which would avoid the need to leak config into the plugin via the configuration input)

from isort-action.