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.

Sign up for GitHub

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

Jump to bottom

Move to uv #540

Merged
merged 20 commits into from
Jan 5, 2025
Merged

Move to uv #540

merged 20 commits into from
Jan 5, 2025

Conversation

rettigl
Copy link
Member

@rettigl rettigl commented Jan 1, 2025

Moves the workflows and packageing system to uv.
Also uses dynamic versioning based on the git tags and commits, and removes the prerelease publishing

Closes #531

@rettigl rettigl mentioned this pull request Jan 2, 2025
Closed
@rettigl rettigl requested a review from zain-sohail January 2, 2025 11:27
@rettigl
Copy link
Member Author

rettigl commented Jan 2, 2025

@zain-sohail release to test-pypi does not work right now, as it goes via your account with is refused because of missing 2FA. However, I believe the workflow is working in general and would be for main pypi. But maybe it's worth testing on test.pypi before merging. For this, you would have to create a "bublisher" there.

@zain-sohail
Copy link
Member

@zain-sohail release to test-pypi does not work right now, as it goes via your account with is refused because of missing 2FA. However, I believe the workflow is working in general and would be for main pypi. But maybe it's worth testing on test.pypi before merging. For this, you would have to create a "bublisher" there.

Fixed that now. Currently uv is adding dev tags which pypi doesn't allow

Uploading sed_processor-0.4.1.dev342+gead1256-py3-none-any.whl
INFO     Response from https://test.pypi.org/legacy/:                           
         400 Bad Request                                                        
INFO     <html>                                                                 
          <head>                                                                
           <title>400 The use of local versions in                              
         <Version('0.4.1.dev342+gead1256')> is not allowed. See                 
         https://packaging.python.org/specifications/core-metadata for more     
         information.</title>                                                   
          </head>                                                               
          <body>                                                                
           <h1>400 The use of local versions in                                 
         <Version('0.4.1.dev342+gead1256')> is not allowed. See                 
         https://packaging.python.org/specifications/core-metadata for more     
         information.</h1>                                                      
           The server could not comply with the request since it is either      
         malformed or otherwise incorrect.<br/><br/>                            
         The use of local versions in                                           
         &lt;Version(&#x27;0.4.1.dev342+gead1256&#x27;)&gt; is not allowed. See 
         https://packaging.python.org/specifications/core-metadata for more     
         information.                                                           
                                                                                
                                                                                
          </body>                                                               
         </html>                                                                
ERROR    HTTPError: 400 Bad Request from https://test.pypi.org/legacy/          
         Bad Request

This is probably not critical to change unless the same thing happens on main. I've not looked at uv in detail yet.

@rettigl
Copy link
Member Author

rettigl commented Jan 3, 2025

Fixed that now. Currently uv is adding dev tags which pypi doesn't allow

I see. For the actual releases, this won't be a problem, but the workflow dispatch action does not make sense then. I actually tested the same approach for the specsanalyzer package already, and it works on release, so we should be good. I will update the workflow accordingly.

zain-sohail
zain-sohail approved these changes Jan 3, 2025
View reviewed changes
Copy link
Member

@zain-sohail zain-sohail left a comment

Choose a reason for hiding this comment

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

LGTM!
Any changes, we can also do later. I think the maintainer docs need to be updated.

@rettigl
Copy link
Member Author

rettigl commented Jan 3, 2025

LGTM! Any changes, we can also do later. I think the maintainer docs need to be updated.

I also updated the docs now. If you want, you can give it a final look.

@zain-sohail
Copy link
Member

LGTM! Any changes, we can also do later. I think the maintainer docs need to be updated.

I also updated the docs now. If you want, you can give it a final look.

Everything looks ok. I just didn't understand why the prereleases were removed from release workflow. Was there a problem with them?

@rettigl
Copy link
Member Author

rettigl commented Jan 4, 2025

I just didn't understand why the prereleases were removed from release workflow. Was there a problem with them?

I did not really see the advantage of having them. If anyone wants a version more recent than the last release, you can always install from git. The problem I had several times with the old workflow was that if you merge a second PR while the pre-release workflow was still running after merging one PR, the version bump would not work because of the intermediate merge commit. As I don't see a reason for having the pre-releases, easiest solution was to remove them. Also, the dynamic dev versions apparently are not allowed on pypi.

@rettigl
Copy link
Member Author

rettigl commented Jan 4, 2025

Here https://discuss.python.org/t/generating-pep-440-compliant-development-releases-containing-githash/12302/4 it is stated:

The recommendation is for development releases to not be distributed via a package index, so Pip won’t have to resolve a development version. I recommend serving the packages using a simple HTTP server (internal or with basic auth), so Pip’s resolution can be bypassed.

@zain-sohail
Copy link
Member

My reason was simply that many users are struggling with git but doing pip install is generally known to most. However, as you pointed out, this is not the recommendation.
We can merge this.

@rettigl rettigl merged commit 178c6ea into v1_feature_branch Jan 5, 2025
6 checks passed
@rettigl rettigl deleted the move_to_uv branch January 5, 2025 21:41
@rettigl rettigl mentioned this pull request Jan 5, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@zain-sohail zain-sohail zain-sohail approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@rettigl @zain-sohail