The purpose of the changes here is to enable Workspace support. A workspace is a place for code and projects. Within the workspace, code can be shared. A workspace is usually at the root of your repository.

To identify a workspace in a Python repo, an empty workspace.toml file is put at the top of the workspace. Future plugins that extends workspaces could use that file to store configuration and settings.

The feature in this pull request will make this this plugin redundant 😄 (I am the author of that plugin)

Why workspaces? A workspace can contain more than one project. Different projects will likely use the same code. A very simplistic example would be a logger. To avoid code duplication, code could be moved out from the project into packages, and each project can reference the package from the project specific pyproject.toml file.

This requires that Poetry allows package includes (note the difference from dependencies) that are "outside" of the project path, but within a workspace. That's what this pull request will do.

An example & simplified tree workspace structure (note the namespacing for shared package includes):

projects/
  my_app/
    pyproject.toml (including a shared package)

  my_service/
    pyproject.toml (including other shared packages)

shared/
  my_namespace/
    my_package/
      __init__.py
      code.py

    my_other_package/
      __init__.py
      code.py

workspace.toml (a file that tells the plugin where to find the workspace root)

I think this feature resolves the issues raised in: https://github.com/python-poetry/poetry/issues/936 and probably also https://github.com/python-poetry/poetry/issues/2270

• [ ] Added tests for changed code.
• [ ] Updated documentation for changed code.

Resolves: python-poetry#241

• [x] Added tests for changed code.
• [x] Updated documentation for changed code.

Feature: ability to add script files to distribution packages

This one is a long overdue, see: https://github.com/sdispater/poetry/issues/241 (June 2018)

The implementation is based on the official specification by @abn https://github.com/python-poetry/poetry/issues/2310

This is a very basic feature of setup.py See here: docs.

Note: this is not the same as entry_point! This setuptools feature basically just copies over the given files to the virtualenv's bin folder so that it'll be available on the $PATH and you can simply invoke it.

Example

[tools.poetry]
package = "my_package"

[tools.poetry.scripts]
migration = { source = "bin/run_db_migrations.sh", type = "file" }
setup_script = { source = "bin/run_setup_script.sh" } # type can be omitted!

Then:

poetry install
poetry run sh run_db_migrations.sh
poetry run sh run_setup_script.sh

Testing

• I added a couple of automated tests
• I tested this manually with one of our repositories and it worked

Hello poetry team,

here is a draft fix for issue python-poetry#6521. It does not currently include a test, as I am not sure how to write a test for it. I tried perusing the unit tests in tests/masonry/builders/test_builder.py and got a bit lost :sweat_smile: Any help or guidance on unit tests would be much appreciated

Documentation... I'm not sure if that's necessary? The purpose of this change is to make poetry do the right thing, instead of failing unexpectedly... I will defer to your judgement on that.

replace usage of pathlib.Path.relative_to with os.path.relpath, as per https://github.com/python-poetry/poetry/issues/5621

Resolves: python-poetry#6521

• [ ] Added tests for changed code.
• [ ] Updated documentation for changed code.

Resolves: https://github.com/python-poetry/poetry/issues/6519

• [x] Added tests for changed code.
• [ ] Updated documentation for changed code.

What this PR contains:

• moves Version.stable to PEP440Version.stable as Version.stable was breaking the precision half of the time.
• adds bunch of test
• fixes Version.next_breaking to allow for version with major == 0

Extra info

It would be great to have to have a poetry build step that checks the requires_dist output against poetry to make sure the package is actually usable.

Resolves: https://github.com/python-poetry/poetry/issues/2062, https://github.com/python-poetry/poetry/issues/2348. Builds on top of #96.

Changes in #96 (copied from here):

This PR allows appending deployment keys to usernames as used by gitlab.

Furthermore a new property is_unsafe is introduced for ParsedUrl, which can be used for cli command like poetry add to easily return whether the git dependency contains a password.

According to gitlab's docs a + is allowed in usernames. This is fixed as well.

Fixes: python-poetry/poetry#2062

(This was initially submitted to the poetry repository: python-poetry/poetry#2169)

Changes I made on top of @finswimmer's work in #96 (rebased to abe9fe5):

• Add tests for when x-oauth-basic GitHub URL is used in package link (https://github.com/python-poetry/poetry/issues/2348).

• Add warning and log for when a dependency stores a password in plain text by using the is_unsafe property (based on discussion in https://github.com/python-poetry/poetry/pull/2169#issuecomment-705587436).

• [x] Added tests for changed code.

• [x] ~Updated documentation for changed code.~ NA

Hoping this is at a good enough point to review and consider merging into main, to be included for a soon-ish release.

PR summary

A declarative approach to extensions using pyproject.toml. Eliminates the need for build.py in many cases.

How to use

Extension modules can now be declared in pyproject.toml:

[tool.poetry.ext_modules.mymodule] sources = ["mymodule/mymodule.c"]

The new logic will validate this config and use it to construct a distutils.extension.Extension object to be passed to distutils.setup()

Config properties

The new logic adds support for all options normally passed to distutils.extension.Extension(), and also within the libraries argument to distutils::setup(). The full list of supported config properties are:

Extension modules [tool.poetry.ext_modules]

• sources (required) - A list of source filenames or globs
• include_dirs - A list of directories to search for C/C++ header files
• define_macros - A list of macros to define; each macro is defined using a 2-tuple (name, value)
• undef_macros - A list of macros to undefine explicitly
• library_dirs - A list of directories to search for C/C++ libraries at link time
• libraries - A list of library names (not filenames or paths) to link against
• runtime_library_dirs - A list of directories to search for C/C++ libraries at run time
• extra_objects - A list of paths or globs of extra files to link with
• extra_compile_args - Any extra platform- and compiler-specific information to use when compiling the source files
• extra_link_args - Any extra platform- and compiler-specific information to use when linking object files together
• export_symbols - A list of symbols to be exported from a shared extension
• depends - A list of paths or globs of files that the extension depends on
• language - The extension language (i.e. 'c', 'c++', 'objc')
• optional - Boolean, specifies that a build failure in the extension should not abort the build process

C libraries [tool.poetry.libraries]

• sources (required) - A list of source filenames or globs
• include_dirs - A list of directories to search for C/C++ header files
• macros - A list of macros to define; each macro is defined using a 2-tuple (name, value)

Why?

I wanted a tool that would limit everything to a single configuration file to do: dependency management, packaging and publishing.

By eliminating the need for build.py in many cases, this PR better accomplishes the stated intent of Poetry (reducing project complexity).

What if I still want to use build.py?

This doesn't stop you, it just gives you another option. If your build logic is too complex (e.g. moving files around), the declarative approach may not be sufficient.

To promote clarity and to reduce the complexity of build logic, this PR doesn't allow you to mix both approaches.

Resolves: python-poetry#

• [ ] Added tests for changed code.
• [ ] Updated documentation for changed code.

More typechecking.

Things that I am not entirely comfortable with:

• returning empty strings from VCSDependency.reference() and VCSDependency.pretty_constraint()
• https://github.com/python-poetry/poetry-core/blob/26e978d3b72ff58039ac921524b5ed47cb8b7353/src/poetry/core/packages/constraints/any_constraint.py#L25 looks like nonsense, what we surely want to return here is some sort of negation of other?
• I've thrown in a few exceptions for places in constraints where cases simply weren't handled. The code would have failed anyway, I've just made it explicit: but still WIBNI these cases were handled

Upstream fix for https://github.com/python-poetry/poetry/pull/2912.

Resolves upstream issue https://github.com/python-poetry/poetry/issues/1556.

Pull Request Check List

• [ ] ~Updated documentation for changed code.~
• [ ] ~Added tests for changed code.~

Both not applicable, docs and tests are added in upstream PR.

Resolves: python-poetry/poetry#6443

• [ ] Added tests for changed code.
• [ ] Updated documentation for changed code.

Didn't add tests as it's just a matter of calling the logger. I also fixed a typo, changing explicitely_<excluded | included> to explicitly_<excluded | included>.

PR for https://github.com/python-poetry/poetry/issues/6443

as per the comment here - https://github.com/python-poetry/poetry/pull/4510

for some reason i had to use different config to successfully exclude the _vendor directory

Currently poetry lock --no-update fails when you remove any path dependency because it first loads all dependencies from the lock file (which still has a reference to the dependency you just deleted) and it fails at that point because when DirectoryDependency is instantiated with a non-existent path it immediately throws an exception.

This change allows the process to continue, which is the same behavior VCS dependencies have.

If the pyproject.toml has a path dependency that doesn't exist we will want to error for poetry install and poetry lock (poetry build with path dependencies is already kinda a no-go). poetry install already fails gracefully (if you lock the project then delete the path dependency and try to install; i.e. when no locking happens before we start installing), I opened https://github.com/python-poetry/poetry/pull/6844 to make poetry lock fail gracefully.

While working on full support for overlapping markers, I encountered a combinatorial explosion when building a union of markers (see test case).

The issue is that we introduced cnf without introducing a counterpart of union_simplify, which leads to unnecessary big markers. Therefore, I added intersect_simplify analoguous to union_simplify.

Further, the simplifications in #530 went a bit too far in removing the common_markers/unique_markers simplification in union_simplify. I reverted this removal and added analogue functionality to intersect_simplify.

Comparing the number of items in itertools.product in dnf of union (after cnf) shows the benefit of the simplifications:

|union (see test case)|number and length of markers in conjunction after cnf|number of items in itertools.product in dnf| |---|---|---| without PR | 31 (1-4) | > 2**44 with simple intersect_simplifiy | 9 (1-2) | 256 with revival of common_markers/unique_markers simplification | 3 (1-2) | 4

Actually the same as #307 which only covered single markers.

The actual fix is in only() of MultiMarker and MarkerUnion. The test shows that get_python_constraint_by_marker() is fixed.

There were some test cases testing the faulty behaviour of only(). I did not only change the expectation (which would have been "" in most cases) but also the input in some cases to cover some more interesting cases.

• [x] Added tests for changed code.
• [ ] Updated documentation for changed code.

glob() returns values in "on disk" order. To make the RECORD file deterministic and consistent between builds we need to sort the data before adding to the records list.

Signed-off-by: Richard Purdie [email protected]

Resolves: python-poetry#

• [ ] Added tests for changed code.
• [ ] Updated documentation for changed code.

Extracted from #402. Besides being a precondition of #402 it's a fix on its own. And it requires some coordination with downstream.

Requires: python-poetry/poetry#7225 and python-poetry/poetry#7236

PEP 440 says:

Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release.

Nothing special about "> pre-release" or ">= pre-release"

Resolves: python-poetry/poetry/issues/7226

• [x] Added tests for changed code.
• [ ] Updated documentation for changed code.

With this change, extras are validated to only contain valid characters and extras that reference dependencies that can't be found in the main dependency group raise a warning in poetry check (not in poetry lock/poetry install, though)