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

[RFC 0045] Deprecating unquoted URL syntax #45

Merged
merged 12 commits into from
Nov 25, 2019
Merged

[RFC 0045] Deprecating unquoted URL syntax #45

Changes from 6 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
ba32469
A small RFC on deprecating URL syntax
7c6f434c Apr 28, 2019
cda4475
Convert alternatives to a list
7c6f434c Apr 28, 2019
e595a19
Add a mention of tooling in future work
7c6f434c Apr 28, 2019
6b39d1b
A remark from @globin about one more problem with unquoted URLs
7c6f434c Apr 28, 2019
268bb83
Grammar edit: comparison of URLs, paths and strings.
FRidh May 1, 2019
ca50c02
Style edit: possibility of future removal
FRidh May 1, 2019
e978077
0045: commit to using the tooling that now exists
7c6f434c May 4, 2019
e0b7512
Merge branch 'url-syntax-deprecation' of https://github.com/7c6f434c/…
7c6f434c May 4, 2019
1773937
Update rfcs/0045-deprecate-url-syntax.md
7c6f434c Jul 18, 2019
cb1d204
Fix shepherd list
7c6f434c Aug 15, 2019
2a99937
Update based on a discussion
7c6f434c Oct 14, 2019
086786a
Explicitly make future removal conditional on editions; restrict the …
7c6f434c Nov 7, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions rfcs/0045-deprecate-url-syntax.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
---
feature: deprecate_url_syntax
start-date: 2019-04-28
author: Michael Raskin
co-authors:
7c6f434c marked this conversation as resolved.
Show resolved Hide resolved
related-issues:
Copy link
Member

Choose a reason for hiding this comment

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

NixOS/nixpkgs#27809
NixOS/nixpkgs#46378

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

---

# Summary
[summary]: #summary

Gradually deprecate the use of unquoted URL syntax in Nix code and especially
Nixpkgs.

# Motivation
[motivation]: #motivation

The Nix language has a special syntax for URLs even though quoted strings can also be used to represent them. Unlike paths, URLs do not
have any special support that would make the difference useful. Moreover, using
variable expansion in URLs requires some URLs to be quoted strings anyway. So
the most consistent approach is to always use quoted strings to represent URLs.
Additionally, a semicolon immediately after the URL can be mistaken for a part
of URL by language-agnostic tools such as terminal emulators.

In case of future breaking changes in the Nix syntax, it would be nice to make
the `x:x` snippet parse to the identity function, and not to an URL. Tools
targeting only Nixpkgs codebase can ignore URL syntax once Nixpkgs phases out
its use.

# Detailed design
[design]: #detailed-design

Add a note in the Nix manual that the special unquoted URL syntax is
deprecated.

Add a note in the Nixpkgs manual that the unquoted URL syntax is deprecated,
changes to Nixpkgs should not increase its use, and it is recommended to
convert URLs to quoted strings when changing them.
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

  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.

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

  2. 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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.


Accept PRs that convert unquoted URLs to quoted strings if such PRs are
submitted.
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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


# Drawbacks
[drawbacks]: #drawbacks

This is a minor cosmetic issue (and maybe a very minor readability issue) which
might not be worth making a specific decision.

# Alternatives
[alternatives]: #alternatives

* Do nothing; get PRs from time to time that make homepages uniformly quoted
strings or uniformly unquoted.

* Decide to use unquoted URLs for all URLs without special characters or
variable expansion.

# Unresolved questions
[unresolved]: #unresolved-questions

Currently none.

# Future work
[future]: #future-work

In case of future major changes in the Nix syntax, removal of special URL
syntax might be considered.

Explore options for automated tracking of the number of unquoted URLs in
Copy link
Member

Choose a reason for hiding this comment

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

If we deprecate this syntax, we should not use it anymore in nixpkgs. so I'd say it should be part of this RFC that all URL's be changed to strings. Writing a program that does this conversion shouldn't be hard, I could write one with hnix.

Copy link
Member Author

Choose a reason for hiding this comment

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

RFC already has a commitment to accept any change like that; I did not put a commitment to make such a change immediately because I was not sure if anyone is willing to commit to write such a tool right now. This is that kind of tool that shouldn't be hard to write, but might end up being annoying to debug, and if nix-fmt happens it should do this as a side-effect anyway…

Copy link
Member

Choose a reason for hiding this comment

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

I'm giving it a shot, I've written a tool that does something very similar before

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! I guess if the tool works, it should be reasonably easy to replace «edit» with «count» and deploy it as an ofBorg check, too?

Nixpkgs.