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

allow arbitrary numbers of / in path tails #9722

Closed
wants to merge 1 commit into from
Closed

allow arbitrary numbers of / in path tails #9722

wants to merge 1 commit into from

Conversation

pennae
Copy link
Contributor

@pennae pennae commented Jan 8, 2024

Motivation

./a/${b} is valid. ./a//${b} is valid. ./a///${b} is invalid. but ./a/${b}///c is valid. this is kind of inconsistent, and considering that we can do path canonicalization outside of the scanner we may as well drop the requirement that slash-runs before the first interpolations be at most 2 long (except for the initial slash of a path which still needs to be restricted, otherwise we'll create ambiguities with the update operator).

this should only accept inputs that were invalid previously. the old behavior of preserving the number of slashes in the final concatenation expression is kept. we do not canonicalize ~ paths because this would break the current ability to create paths that'll traverse out of ~.

Context

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

./a/${b} is valid. ./a//${b} is valid. ./a///${b} is invalid. but
./a/${b}///c is valid. this is kind of inconsistent, and considering
that we can do path canonicalization outside of the scanner we may as
well drop the requirement that slash-runs before the first
interpolations be at most 2 long (except for the initial slash of a
path which still needs to be restricted, otherwise we'll create
ambiguities with the update operator).

this should only accept inputs that were invalid previously. the old
behavior of preserving the number of slashes in the final concatenation
expression is kept. we do not canonicalize ~ paths because this would
break the current ability to create paths that'll traverse out of ~.
@pennae pennae requested a review from edolstra as a code owner January 8, 2024 20:54
@github-actions github-actions bot added the with-tests Issues related to testing. PRs with tests have some priority label Jan 8, 2024
@edolstra
Copy link
Member

edolstra commented Jan 9, 2024

except for the initial slash of a path which still needs to be restricted

Also, paths starting with two slashes are UNC paths. Since we don't know how to handle those, we should (continue to) disallow them.

@roberth
Copy link
Member

roberth commented Jan 12, 2024

disallow them.

Not necessarily in the parser, but shortly after? Might be simpler that way, and it's good to make it explicitly reserved syntax. (certainly if we don't steal any existing syntax)

@pennae
Copy link
Contributor Author

pennae commented Jan 12, 2024

we cannot change the path syntax to accept absolute //-prefixed paths without breaking compatibility. unc-style /-prefixed paths just can't be a thing (and in any case we'd much rather add new syntax for explicit path literals that cannot be prefixed with valid identifiers, eg (exposition only!) by turning $/ into an explicit path leader)

@pennae
Copy link
Contributor Author

pennae commented Jan 23, 2024

closing as discussed in favor of keeping the current behavior around for a while longer.

@pennae pennae closed this Jan 23, 2024
@thufschmitt
Copy link
Member

Discussed during the Nix maintainers meeting on 2024-01-22.
No decision, but #8738 might be the right long-term solution.

We're confused why the the multiple tail slash (`...//...`) examples work today.
  • @roberth: seems like we really need to audit the grammar, and might want to deprecate multiple slashes rather than add more support for them.

  • @Ericson2314: c.f. no-absolute-path-literals experimental feature #8738, a more ambitious idea for deprecating path syntax.

  • @Ericson2314: It seems we either want multiple slashes everywhere, or nowhere. The current complicated behavior of being allowed somewhere is definitely worse than both of those.

  • @edolstra: guess yeah it is fine for debugging / plumbing purposes as long as it is not recommended.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-01-22-nix-team-meeting-minutes-117/38838/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
with-tests Issues related to testing. PRs with tests have some priority
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants