Release 1.1.0a7

[finswimmer]

Fixed

• Fixed an issue when evaluate in/not in markers (#188).
• Fixed an issue when parsing of caret constraint with leading zero (#201).
• Respect format for explicit included files when finding excluded files (#228).
• Fixed an issue where only the last location was used when multiple packages should be included (#108).
• Ensure that package description contains no new line (#219).
• Fixed an issue where all default dependencies were removed instead of just the selected one (#220).
• Ensure that authors and maintainers are normalized (#276).

Added

• Add support for most of the guaranteed hashes (#207).
• Add support to declare multiple README files (#248).
• Add support for git sub directories (#192).
• Add hooks according to PEP-660 for editable installs (#182).
• Add support for version epochs (#264).

Changed

• Drop python3.6 support (#263).
• Loose the strictness when parsing version constraint to support invalid use of wildcards, e.g. >=3.* (#186).
• No longer assume a default git branch name (#192).
• Sort package name in extras to make it reproducible (#280).

Improvements

• Improve marker handling (#208,
  #282,
  #283,
  #284,
  #286,
  #291,
  #293,
  #294,
  #297).

[dimbleby]

A release sounds good! But there are a few MRs queued that I would be glad to see merged first, I think most or all of these should be fairly quick to complete.

Fixes:

• Marker name is a string, not a lexer token #286 is a really trivial and obviously safe fix
• recalculate python markers on dependency more often #284 is also straightforward, it feels a little more likely to expose bugs elsewhere but I think is fairly clearly correct in itself
• maybe Ensure that authors and maintainers are normalized. #276, hard to see it doing harm anyway

Then there are some nice tidy-ups which I guess are largely cosmetic but they also look to me as though they should be ready to merge:

• Improve constraint union #283, Marker simplifications #282 produce simplifications in markers and constraints
• typechecking poetry.core.masonry #274 and Update type hints of PEP440Version class #270 improve the typechecking, the first of them perhaps would want more than a cursory check. (It's mine and of course I think it's fine! but I acknowledge that it's not so trivial as the others)

And though I don't know this one so well myself: #221 is already approved, is it waiting on anything?

[radoering]

Is there a reason why the naming pattern is changed? And why is it changed here, but not in __init__.py?

[finswimmer]

Good point 👍 I bumped the version via poetry version and this uses SemVer nomenclature in the pyproject.toml. I guess this was done before manually.

I've change the __init__.py file to read the version now via importlib. So we can avoid duplicate places for the version number.

[finswimmer]

I've change the init.py file to read the version now via importlib. So we can avoid duplicate places for the version number.

hm, seems to be problematic, because poetry-core needs to build itself. Will revert it.

[radoering]

OK, but both "versions" should at least be equal, shouldn't they?

[finswimmer]

Jaein :) Within the __init__.py file the version should follow PEP 440. When poetry installs the package it translate the semver notation from the pyproject.toml into a PEP 440 compliant form. Whether poetry should create the version in the pyproject.toml in PEP 440 by default is another story, which we should discuss at some point.

[radoering]

While reading the part about normalization, I thought the same: "seems to be valid, just not normalized". However, the part about compatibility with semantic versioning says "Semantic versions containing a hyphen (pre-releases - clause 10) or a plus sign (builds - clause 11) are not compatible with this PEP and are not permitted in the public version field."

Maybe, versions which are not normalized are not considered PEP440 compliant but only have to be tolerated for compatibility reasons?

[dimbleby]

Or, you could avoid all this confusion by releasing plain old 1.1.0...

What is the reason for alpha releases of poetry-core? Just ship what's good now, and ship fixes / additions / changes in 1.1.1 / 1.2.0 / 2.0.0. There's no shortage of version numbers.

(Possibly a conversation for another place, but I'd encourage a poetry 1.2.0 release too... do point me at it if this is being discussed somewhere. There are lots of fixes stored up in master that are never going to get back-applied to the 1.1 branch, let's release them)

[finswimmer]

I understand PEP-440 in that way that -alpha.7 is compliant in that way, that parser have to accept it, but it's not allowed to write 🤷‍♂️

@dimbleby: I'm not sure at the moment if something is missing or to unstable to release a 1.1.0 of poetry-core. A poetry 1.2 is definitely not possible yet, because the plugin system is not enough stable.

So @python-poetry/core: Is there something that should be changed here now or can we go on releasing?

[dimbleby]

I'm not sure at the moment if something is missing or to unstable to release a 1.1.0 of poetry-core

It's complete / stable enough to be used by poetry - as demonstrated by its master branch. I don't see users from any other projects asking for additions or fixes.

A poetry 1.2 is definitely not possible yet, because the plugin system is not enough stable.

Then my suggestion would be to cut a release, but declare that the plugin system is not yet stable.

(Unless there's some work to bring that desired stability which is nearing completion, in which case it might be worth waiting for it. But I get the impression that we are likely to be waiting for some time, and it's a shame to let the perfect be the enemy of the good.)

[finswimmer]

We discussed it whether we want to call the release 1.1.0. We decided to keep it as an alpha release until we are sure enough that there are no more big changes needed before the poetry 1.2.0 release.

[radoering]

I skimmed the changes and think the most important issues are covered.

Some minor nitpicks (you may or may not want to change 😉):

• Perhaps, Ensure setting dependency marker sets the python constraint #208 could be added to "Improve marker handling".
• At the first point, a space is missing in front of the opening bracket.
• If you still adjust anything, you could harmonize the punctuation, e.g. dot at the end of each point after the PR number.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication