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

treat collections in packages as immutable #663

Merged
merged 3 commits into from
Jan 23, 2024

Conversation

dimbleby
Copy link
Contributor

intended as a more-or-less maintainable version of #618. See also python-poetry/poetry#8671

by annotating collection types in packages as immutable, we "prove" that the shallow copy is a safe way to clone them

of course this is still not too hard to break: just by adding in something mutable later.

I see performance improvement during locking by about 20-25% on a couple of sample projects. It's not a complete no-brainer to me that this is change is safe enough to accept, but I think it probably is: and that's a good amount of performance to leave on the table. Still, I'm ready to be overruled.

@radoering
Copy link
Member

I tend to say it's worth it.

of course this is still not too hard to break: just by adding in something mutable later.

Maybe, we should add a comment in the __init__ methods of PackageSpecification, Package and Dependency just before the attributes are defined. Something like "Attributes must be immutable so that clone() is safe! (For performance reasons, clone just creates a copy instead of a deepcopy.)" It's still not much but at least it's as close as possible to the place where the disaster will happen.

Is there a reason why you left ProjectPackage alone? It inherits from Package and has some additional mutable attributes. I did not check but I suppose it does not matter because we only have one ProjectPackage and probably don't care about cloning. If we want to be safe without spending too much effort we could also override clone in ProjectPackage to make a deepcopy. I don't have a preference yet...

@dimbleby
Copy link
Contributor Author

both of your suggestions sound reasonable: if you're active and interested then feel free to make updates directly else I'll try to get to it - but likely not for at least a few days

Copy link

sonarcloud bot commented Nov 18, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

Copy link
Member

@radoering radoering left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For transparency: I'm planning to merge this shortly before the core release because I think merging it now without a release will make development on other Poetry PRs that require core changes more difficult.

Copy link

sonarcloud bot commented Jan 23, 2024

Quality Gate Passed Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

@radoering radoering merged commit 5639997 into python-poetry:main Jan 23, 2024
19 checks passed
@dimbleby dimbleby deleted the shallow-copy branch January 23, 2024 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants