[RFC 0045] Deprecating unquoted URL syntax

[7c6f434c]

No description provided.

[grahamc]

I'm in favor of this RFC.

[grahamc]

Mind making these two items a list?

[7c6f434c]

Definitely done in the PR branch, I have no idea why GitHub doesn't show this yet…

[grahamc]

I wonder if there is a way ofborg could detect newly introduced URL values?

[7c6f434c]

Maybe your profiling patch to Nix is in the right direction for that…

[joepie91]

Strongly in favour. It's never been clear to me why this was part of the syntax, and more than once I've been left with analysis paralysis because I wasn't sure whether there was a reason to use the special syntax or not, and there appeared to be no documentation on that.

And from a tooling implementor POV: removing this in the long run would reduce the complexity of a Nix (parser) implementation.

[peti]

Yes, please remove the special URL syntax! That feature adds very little value (if any) and I've never needed it.

[samueldr]

Quick thoughts about deprecating language/interpreter features:

As far as detection goes, deprecating features in the interpreter could be made strict with a list of "new" features, e.g. --option strict-eval no-unquoted-urls so that the interpreter gates everything related to the unquoted URLs under conditionals, making it fail. Tracing could additionally be added at the same locations to warn, hopefully with a flag to disable tracing those.

Though, this is all at the cost of adding more conditionals, thus more possibilities for weird behaviours.

Gating it in the main interpreter with an option would also allow end-users to set it globally, allowing new deprecation-free evals to be forced on their systems, hopefully helping weed out the leftover features deprecations.

[globin]

I agree!

Another thing with unquoted URLs is that most terminals treat the ; as part of the url making it harder to copy/click links with the special syntax.

[7c6f434c]

Thanks for the suggestion of one more reason, let's have motivation section be the longest one!

[zimbatm]

👍 happy to see this happening

[zimbatm]

Is it possible to be more specific? How would everybody be notified about this new rule?

[7c6f434c]

1. I think the mere fact of an RFC passing is a noticeable effect event for a large fraction of active contributors. (It is visible in this repository, announced via Discourse, gets into the «weekly», is likely to be discussed a bit on IRC etc.)

For this specific RFC just the announcement «RFC on Deprecation of URL syntax passed» conveys enough information.

2. It will be noted in two out of three manuals.

3. Once we have an RFC that something «should not» happen, a request for cosmetic cleanup in a PR (and such requests happen) is more likely to contain a mention of quoting URLs (if relevant for the package in question). This also spreads the knowledge.

I do have an impression that quite a few people mentioned that they are disappointed they cannot refer to a policy that quoted URLs are better, so I expect the review channel of information dissemination to perform well.

Appendix A: future work — maybe the tool gets implemented, then we can open a countdown issue and maybe make ofborg check that PRs do not make things worse).

My plan is indeed just these points. I think that these things do not really need any additions to the text of RFC, and I think these mechanisms will be enough to distribute the information.

If you think that any of these four channels benefit from an addition to RFC text, or that there are other information distribution channels that should be used (and mentioned in the RFC text) please give some details.

[zimbatm]

It doesn't have to be formalized in the RFC but it's good to have an accompanying discussion.

For example you mentioned "they are disappointed they cannot refer to a policy". Would the RFC act as such policy? If not, maybe we should have a list of official policies in place.

[7c6f434c]

I think having a deprecation notice in the manual (added in accordance with an explicit bullet point in an approved/accepted RFC) is close enough to official policy for the purpose of asking people not to do the deprecated things.

I didn't start the discussion myself, because I thought that (1) is assumed, (2) and (A) are explicitly mentioned, and (3) is a manual variant of (A) in a sense.

[FRidh]

NixOS/nixpkgs#27809
NixOS/nixpkgs#46378

[7c6f434c]

I am not sure: the RFC template seems to imply this is for PRs implementing the RFC, not for the changes the RFC intends to undo.

[7c6f434c]

@FRidh thanks for the proofreading.

[edolstra]

We should not break backwards compatibility in such a massive way. I mean, deprecation is only useful if you eventually want to remove it, at which point it becomes impossible for Nix to build old Nix expressions.

In principle, the flakes "epoch" feature would make it possible to make such language changes in a backward compatible way (e.g. unquoted URLs could be deprecated in epoch 2020). I'm not convinced it's actually useful, though. The case of x:x falls under the "just don't do that" header IMHO.

[7c6f434c]

There are some features that we have chosen not to use in Nixpkgs anymore and we do not recommend to use these features if they can be avoided at all. Additional tooling intended for aiding Nixpkgs development can be useful without supporting such features, and easier creation of tooling is good.

The RFC definitely does not argue for actually dropping the support unless some other breaking changes happen. It will be a pity if an epoch-guarded syntax change for something major like a change in overrides happens without a cleanup of minor annnoyances.

[domenkozar]

In 2022 we can parse Nix identifier without first parsing a URI with a regex, which will speed up the parser.

[edolstra]

@domenkozar I think URIs, identifiers etc. are all recognized using a single finite state machine, so it shouldn't matter much for performance.

[nixos-discourse]

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

https://discourse.nixos.org/t/nix-2-4-released/15822/1