Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nox-poetry does not respect the new dependency groups from Poetry #977

Closed
paw-lu opened this issue Nov 27, 2022 · 4 comments · Fixed by #1139 · May be fixed by #1080
Closed

nox-poetry does not respect the new dependency groups from Poetry #977

paw-lu opened this issue Nov 27, 2022 · 4 comments · Fixed by #1139 · May be fixed by #1080

Comments

@paw-lu
Copy link
Contributor

paw-lu commented Nov 27, 2022

Poetry has now deprecated --dev, and instead uses different named groups via --group. Eg:

% poetry add flask
% poetry add --group foo black

Since nox-poetry currently uses something like poetry export --dev --format=requirements.txt, this does not include dependencies defined in other groups—like group foo above. (Worth noting that this still works for the dev group though.)

There currently does not seem to be a way to force poetry export to export all dependencies. See:

@paw-lu
Copy link
Contributor Author

paw-lu commented Nov 28, 2022

This doesn't solve the above problem completely, but I wonder if it makes sense to add an install_groups to Session? It should take multiple values since Poetry does as well.

eg:

def bar(session: Session) -> None:
    """Install depenencies from group 'foo' and 'baz'."""
    session.install_groups("foo", "baz")
% nox --session bar
poetry export --format=requirements.txt --with foo --with baz --without-hashes
python -m pip install --requirements=.nox/path/to/requirements.txt

@johnthagen
Copy link

johnthagen commented Jan 3, 2023

Related/duplicate of:

See also:

jherland added a commit to tweag/FawltyDeps that referenced this issue Jan 4, 2023
Use shell.nix to bring in all Python versions that we want to support.
Also bring in Nox via its own dependency group.

This, together with noxfile.py defines a set of new "actions" that we
can run locally (and maybe also in CI in a future commit). For now we
define three actions:

  - tests (run on all supported Python versions)
  - format (run formatting actions)
  - lint (run linters)

Examples of how to run this:

  - nox -s tests  # Run test suite on all supported Python versions
  - nox -s tests-3.7  # Run test suite on v3.7 only
  - nox -s format  # Run formatting action (black + isort)
  - nox -s lint  # Run linters (mypy, pylint, isort, black)
  - nox  # Run all of the above

Some complications worth mentioning:

We have organized our dependencies using Poetry dependency groups (see
[1] for more information on those), and we would therefore like to use
those groups when telling Nox which dependencies are needed for each
of the Nox actions described above.

However, we cannot use `poetry install ...` to install these
dependencies, because Poetry insists on installing into its own
virtualenv - i.e. NOT the virtualenv that Nox creates for each session.

We could have used nox-poetry (https://github.com/cjolowicz/nox-poetry),
but unfortunately it does not support Poetry dependency groups, yet[2].

The workaround/solution is to export the required dependency groups from
Poetry into a requirements.txt file that we can then pass on to Nox's
session.install(). This is implemented by the install_groups() helper
function in our noxfile.py.

On my work laptop, the nox command (i.e. running all of the actions)
completes in ~50s for the initial run, and ~17s on subsequent runs
(when Nox can reuse its per-session virtualenvs).

[1]: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups

[2]: see cjolowicz/nox-poetry#895 or
cjolowicz/nox-poetry#977 for more discussion.
jherland added a commit to tweag/FawltyDeps that referenced this issue Jan 4, 2023
Use shell.nix to bring in all Python versions that we want to support.
Also bring in Nox via its own dependency group.

This, together with noxfile.py defines a set of new "actions" that we
can run locally (and maybe also in CI in a future commit). For now we
define three actions:

  - tests (run on all supported Python versions)
  - format (run formatting actions)
  - lint (run linters)

Examples of how to run this:

  - nox -s tests  # Run test suite on all supported Python versions
  - nox -s tests-3.7  # Run test suite on v3.7 only
  - nox -s format  # Run formatting action (black + isort)
  - nox -s lint  # Run linters (mypy, pylint, isort, black)
  - nox  # Run all of the above

Some complications worth mentioning:

We have organized our dependencies using Poetry dependency groups (see
[1] for more information on those), and we would therefore like to use
those groups when telling Nox which dependencies are needed for each
of the Nox actions described above.

However, we cannot use `poetry install ...` to install these
dependencies, because Poetry insists on installing into its own
virtualenv - i.e. NOT the virtualenv that Nox creates for each session.

We could have used nox-poetry (https://github.com/cjolowicz/nox-poetry),
but unfortunately it does not support Poetry dependency groups, yet[2].

The workaround/solution is to export the required dependency groups from
Poetry into a requirements.txt file that we can then pass on to Nox's
session.install(). This is implemented by the install_groups() helper
function in our noxfile.py.

On my work laptop, the nox command (i.e. running all of the actions)
completes in ~50s for the initial run, and ~17s on subsequent runs
(when Nox can reuse its per-session virtualenvs).

[1]: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups

[2]: see cjolowicz/nox-poetry#895 or
cjolowicz/nox-poetry#977 for more discussion.
jherland added a commit to tweag/FawltyDeps that referenced this issue Jan 5, 2023
Use shell.nix to bring in all Python versions that we want to support.
Also bring in Nox via its own dependency group.

This, together with noxfile.py defines a set of new "actions" that we
can run locally (and maybe also in CI in a future commit). For now we
define three actions:

  - tests (run on all supported Python versions)
  - format (run formatting actions)
  - lint (run linters)

Examples of how to run this:

  - nox -s tests  # Run test suite on all supported Python versions
  - nox -s tests-3.7  # Run test suite on v3.7 only
  - nox -s format  # Run formatting action (black + isort)
  - nox -s lint  # Run linters (mypy, pylint, isort, black)
  - nox  # Run all of the above

Some complications worth mentioning:

We have organized our dependencies using Poetry dependency groups (see
[1] for more information on those), and we would therefore like to use
those groups when telling Nox which dependencies are needed for each
of the Nox actions described above.

However, we cannot use `poetry install ...` to install these
dependencies, because Poetry insists on installing into its own
virtualenv - i.e. NOT the virtualenv that Nox creates for each session.

We could have used nox-poetry (https://github.com/cjolowicz/nox-poetry),
but unfortunately it does not support Poetry dependency groups, yet[2].

The workaround/solution is to export the required dependency groups from
Poetry into a requirements.txt file that we can then pass on to Nox's
session.install(). This is implemented by the install_groups() helper
function in our noxfile.py.

On my work laptop, the nox command (i.e. running all of the actions)
completes in ~50s for the initial run, and ~17s on subsequent runs
(when Nox can reuse its per-session virtualenvs).

[1]: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups

[2]: see cjolowicz/nox-poetry#895 or
cjolowicz/nox-poetry#977 for more discussion.
jherland added a commit to tweag/FawltyDeps that referenced this issue Jan 9, 2023
Use shell.nix to bring in all Python versions that we want to support.
Also bring in Nox via its own dependency group.

This, together with noxfile.py defines a set of new "actions" that we
can run locally (and maybe also in CI in a future commit). For now we
define three actions:

  - tests (run on all supported Python versions)
  - lint (run linters)
  - reformat (run formatting actions)

Examples of how to run this:

  - nox -s tests  # Run test suite on all supported Python versions
  - nox -s tests-3.7  # Run test suite on v3.7 only
  - nox -s reformat  # Run formatting action (black + isort)
  - nox -s lint  # Run linters (mypy, pylint, isort, black)
  - nox  # Run all of the above

Some complications worth mentioning:

We have organized our dependencies using Poetry dependency groups (see
[1] for more information on those), and we would therefore like to use
those groups when telling Nox which dependencies are needed for each
of the Nox actions described above.

However, we cannot use `poetry install ...` to install these
dependencies, because Poetry insists on installing into its own
virtualenv - i.e. NOT the virtualenv that Nox creates for each session.

We could have used nox-poetry (https://github.com/cjolowicz/nox-poetry),
but unfortunately it does not support Poetry dependency groups, yet[2].

The workaround/solution is to export the required dependency groups from
Poetry into a requirements.txt file that we can then pass on to Nox's
session.install(). This is implemented by the install_groups() helper
function in our noxfile.py.

On my work laptop, the nox command (i.e. running all of the actions)
completes in ~50s for the initial run, and ~17s on subsequent runs
(when Nox can reuse its per-session virtualenvs).

[1]: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups

[2]: see cjolowicz/nox-poetry#895 or
cjolowicz/nox-poetry#977 for more discussion.
jherland added a commit to tweag/FawltyDeps that referenced this issue Jan 9, 2023
Use shell.nix to bring in all Python versions that we want to support.
Also bring in Nox via its own dependency group.

This, together with noxfile.py defines a set of new "actions" that we
can run locally (and maybe also in CI in a future commit). For now we
define three actions:

  - tests (run on all supported Python versions)
  - lint (run linters)
  - reformat (run formatting actions)

Examples of how to run this:

  - nox -s tests  # Run test suite on all supported Python versions
  - nox -s tests-3.7  # Run test suite on v3.7 only
  - nox -s reformat  # Run formatting action (black + isort)
  - nox -s lint  # Run linters (mypy, pylint, isort, black)
  - nox  # Run all of the above

Some complications worth mentioning:

We have organized our dependencies using Poetry dependency groups (see
[1] for more information on those), and we would therefore like to use
those groups when telling Nox which dependencies are needed for each
of the Nox actions described above.

However, we cannot use `poetry install ...` to install these
dependencies, because Poetry insists on installing into its own
virtualenv - i.e. NOT the virtualenv that Nox creates for each session.

We could have used nox-poetry (https://github.com/cjolowicz/nox-poetry),
but unfortunately it does not support Poetry dependency groups, yet[2].

The workaround/solution is to export the required dependency groups from
Poetry into a requirements.txt file that we can then pass on to Nox's
session.install(). This is implemented by the install_groups() helper
function in our noxfile.py.

On my work laptop, the nox command (i.e. running all of the actions)
completes in ~50s for the initial run, and ~17s on subsequent runs
(when Nox can reuse its per-session virtualenvs).

[1]: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups

[2]: see cjolowicz/nox-poetry#895 or
cjolowicz/nox-poetry#977 for more discussion.
@cjolowicz
Copy link
Owner

I agree that the constraints file should include all dependency groups. We could handle this similarly to how we handle extras here:

*[f"--extras={extra}" for extra in self.config.extras],

@cjolowicz
Copy link
Owner

cjolowicz commented Jul 8, 2023

This was fixed in nox-poetry 1.0.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants