Add parsed URL fields to Dist variants #3429
Merged
Merged
Conversation
031e457 to
18ac8e9
Compare
1e35e0a to
b6832d2
Compare
18ac8e9 to
d907037
Compare
b6832d2 to
9b79279
Compare
a014c75 to
7a1d730
Compare
9b79279 to
4b85300
Compare
7a1d730 to
cd59a38
Compare
4b85300 to
136f6b5
Compare
136f6b5 to
669ace4
Compare
konstin
commented
May 8, 2024
| /// The url without subdirectory fragment. | ||
| pub location: Url, | ||
| pub subdirectory: Option<PathBuf>, | ||
| /// The url with subdirectory fragment. |
Member
Author
There was a problem hiding this comment.
The intention is to eventually remove the VerbatimUrl, leaving only given: String, for now we just eliminate the fallible re-parsing of urls
konstin
commented
May 8, 2024
| pub struct GitSourceDist { | ||
| pub name: PackageName, | ||
| /// The url without revision and subdirectory fragment. | ||
| pub git: Box<GitUrl>, |
Member
Author
There was a problem hiding this comment.
Without boxing, this would increase the size of the entire Dist
konstin
commented
May 8, 2024
| // At time of writing, Unix is at 240, Windows is at 248. | ||
| assert!( | ||
| std::mem::size_of::<Dist>() <= 248, | ||
| std::mem::size_of::<Dist>() <= 336, |
Member
Author
There was a problem hiding this comment.
I have a branch boxing the entire Dist struct, but it didn't help with the windows debug stack overflows.
konstin
commented
May 8, 2024
| )?; | ||
|
|
||
| let ParsedUrl::Archive(archive) = ParsedUrl::try_from(args.url.to_url())? else { | ||
| bail!("Only https is supported"); |
Member
Author
There was a problem hiding this comment.
This is just the dev script
konstin
commented
May 8, 2024
| path: _, | ||
| path, | ||
| url, | ||
| // TODO(konsti): Figure out why we lose the editable here (does it matter?) |
Member
Author
There was a problem hiding this comment.
This was introduced with cf30932#diff-49326157b193e4affae1b7a1c56c7c7e1ea2039168e33948b6c30a4fe7f4ef9eR76, where the Dist::from_url dropped the information. Is there an argument that the lookahead should or shouldn't consider editables?
Member
There was a problem hiding this comment.
I think it's because we currently assume editables can't be transitive deps.
54fd266 to
9e653c3
Compare
669ace4 to
33dbaa2
Compare
8cd479e to
8de4b2d
Compare
33dbaa2 to
49ea7cd
Compare
Dist variants
konstin
added a commit
that referenced
this pull request
Feb 14, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allow file schemes, which apparently work with Git out of the box. A caveat for this is that in `tool.uv.sources`, we parse the `git` field always as URL. This caused a problem with #11425: `repo = { git = 'c:\path\to\repo', rev = "xxxxx" }` was parsed as a URL where `c:` is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place * Allows `file:` URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does _not_ allow relative paths in the `git` field in `tool.uv.sources`. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards `file:`. If there's still desire for a relative path, we can reopen.
konstin
added a commit
that referenced
this pull request
Feb 14, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allow file schemes, which apparently work with Git out of the box. A caveat for this is that in `tool.uv.sources`, we parse the `git` field always as URL. This caused a problem with #11425: `repo = { git = 'c:\path\to\repo', rev = "xxxxx" }` was parsed as a URL where `c:` is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place * Allows `file:` URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does _not_ allow relative paths in the `git` field in `tool.uv.sources`. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards `file:`. If there's still desire for a relative path, we can reopen.
konstin
added a commit
that referenced
this pull request
Feb 14, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allow file schemes, which apparently work with Git out of the box. A caveat for this is that in `tool.uv.sources`, we parse the `git` field always as URL. This caused a problem with #11425: `repo = { git = 'c:\path\to\repo', rev = "xxxxx" }` was parsed as a URL where `c:` is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place * Allows `file:` URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does _not_ allow relative paths in the `git` field in `tool.uv.sources`. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards `file:`. If there's still desire for a relative path, we can reopen.
konstin
added a commit
that referenced
this pull request
Feb 17, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allow file schemes, which apparently work with Git out of the box. A caveat for this is that in `tool.uv.sources`, we parse the `git` field always as URL. This caused a problem with #11425: `repo = { git = 'c:\path\to\repo', rev = "xxxxx" }` was parsed as a URL where `c:` is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place * Allows `file:` URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does _not_ allow relative paths in the `git` field in `tool.uv.sources`. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards `file:`. If there's still desire for a relative path, we can reopen.
konstin
added a commit
that referenced
this pull request
Feb 17, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allow file schemes, which apparently work with Git out of the box. A caveat for this is that in `tool.uv.sources`, we parse the `git` field always as URL. This caused a problem with #11425: `repo = { git = 'c:\path\to\repo', rev = "xxxxx" }` was parsed as a URL where `c:` is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place * Allows `file:` URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does _not_ allow relative paths in the `git` field in `tool.uv.sources`. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards `file:`. If there's still desire for a relative path, we can reopen.
charliermarsh
added a commit
that referenced
this pull request
Feb 18, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allowed file schemes, which apparently work with Git out of the box. A caveat for this is that in tool.uv.sources, we parse the git field always as URL. This caused a problem with #11425: repo = { git = 'c:\path\to\repo', rev = "xxxxx" } was parsed as a URL where c: is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place. It bans everything but HTTPS, SSH, and file URLs. This could be a breaking change, if users were using a git transport protocol were not aware of, even though never intentionally supported. * Allows file: URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does not allow relative paths in the git field in tool.uv.sources. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards file:. If there's still desire for relative path support, we can keep it open. --------- Co-authored-by: Charlie Marsh <[email protected]>
loic-lescoat
pushed a commit
to loic-lescoat/uv
that referenced
this pull request
Mar 2, 2025
Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in astral-sh#3429. This incidentally allowed file schemes, which apparently work with Git out of the box. A caveat for this is that in tool.uv.sources, we parse the git field always as URL. This caused a problem with astral-sh#11425: repo = { git = 'c:\path\to\repo', rev = "xxxxx" } was parsed as a URL where c: is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place. It bans everything but HTTPS, SSH, and file URLs. This could be a breaking change, if users were using a git transport protocol were not aware of, even though never intentionally supported. * Allows file: URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does not allow relative paths in the git field in tool.uv.sources. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes astral-sh#3429: We reject the input with a proper error message, while hinting the user towards file:. If there's still desire for relative path support, we can keep it open. --------- Co-authored-by: Charlie Marsh <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Avoid reparsing urls by storing the parsed parts across resolution on
Dist.Part 2 of #3408 and part of #3409
Closes #3408