exporting packages with features

[dimbleby]

Fix for #5537, see also python-poetry/poetry-plugin-export#65

Have get_project_dependency_packages() return packages with features suitably set, so that the exporter can record them. Features are accumulated as we walk the tree.

With that set of fixes, this test sees this diff

-localstack-ext==1.0.0 ; {MARKER_PY36}
-localstack==1.0.0 ; {MARKER_PY36}
+localstack-ext[bar]==1.0.0 ; {MARKER_PY36}
+localstack[foo]==1.0.0 ; {MARKER_PY36}

which is python-poetry/poetry-plugin-export#66

Direct manipulation of _extras is not great, we should add set_extras(extras) or similar in poetry-core. That's a little exciting - _extras gets hashed so careless callers can go wrong - but it's not worse than set_constraint() as also used by the locker (and, similarly, is safe to do in this code).

Also we can remove requires_extras from poetry-core, it's unused.

[dimbleby]

I don't know what order these things can all be committed in to keep the tests passing at all times!

[abn]

Thanks @dimbleby for picking this up. Some comments in relation to fixing the duplicated attributes in core's Dependency implementation.

[abn]

One possible order for these changes could be as follows.

1. Add a || true to the export test command in ci so the workflow does not bail
2. Relock the dev dependency in the export plugin in fixed testcase exporting extras poetry-plugin-export#66
3. Make a new release of the export plugin
4. Update plugin version on poetry and undo (1).

In the long term we need to fix this coupling somehow :(

[dimbleby]

Long-term, I suppose that this repository should simply not know anything about poetry-plugin-export; because that plugin should be no more special than any other.

(Also that would fix the circular dependency where both projects depend on one another).

Perhaps we can just do that now, must we test the export plugin from here?

[abn]

Perhaps we can just do that now, must we test the export plugin from here?

It is possible yes. However, might require a deprecation cycle for the command itself. The issue is export command has been a core poetry command, and changes in poetry can break the export command. The tests were introduced because of one such case a while back where poetry export broke badly.

[dimbleby]

reworked fix is now simpler, and exports like this in that existing testcase:

 localstack-ext==1.0.0 ; {MARKER_PY36}
-localstack==1.0.0 ; {MARKER_PY36}
+localstack-ext[bar]==1.0.0 ; {MARKER_PY36}
+localstack[foo]==1.0.0 ; {MARKER_PY36}

ie we get both localstack-ext and localstack-ext[bar]

This is cosmetically ugly when, as here, both variations have the same markers. But in cases where they have different markers eg some extra is required on windows only - this seems like it is giving the right answers where the previous try didn't.

Indeed something like this is the case in #5537, where what we now export is:

google-api-core==1.22.0 ; python_version >= "3.8" and python_version < "4.0"
google-api-core[grpc]==1.22.0 ; python_version >= "3.8" and python_version < "4.0" and platform_python_implementation != "PyPy"

it would have been a mistake to combine this into

google-api-core[grpc]==1.22.0 ; python_version >= "3.8" and python_version < "4.0"

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.