Patchwork [3,of,5,paths,v3] ui.paths: filter config options containing "." (BC)

login
register
mail settings
Submitter Gregory Szorc
Date March 8, 2015, 7:54 p.m.
Message ID <0f9c6588afcbaaca41b8.1425844456@vm-ubuntu-main.gateway.sonic.net>
Download mbox | patch
Permalink /patch/7943/
State Changes Requested
Delegated to: Pierre-Yves David
Headers show

Comments

Gregory Szorc - March 8, 2015, 7:54 p.m.
# HG changeset patch
# User Gregory Szorc <gregory.szorc@gmail.com>
# Date 1425243224 28800
#      Sun Mar 01 12:53:44 2015 -0800
# Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
# Parent  57681bad997779da88778ff95254951c89250441
ui.paths: filter config options containing "." (BC)

Upcoming patches will enable additional attributes to be defined
on a per-path basis. This will be done by creating config options
of the form "path.X" and "path.Y."

This patch teaches the new paths API to assume options containing
"." are per-path attributes and not valid path names.

This patch is technically backwards incompatible because nothing
was preventing people from using "." in path names. However, the
author feels this convention is not widespread enough to warrant
maintaining backwards compatibility. If backwards compatibility
is needed, we'll have to employ different functionality for
defining per-path attributes, such as separate config sections
per path. An earlier version of this patch series did feature
separate config sections per path. However, people felt that
adopting sub-options was a better approach since this is done
elsewhere (such as with merge tool definition).
Pierre-Yves David - March 10, 2015, 3:10 a.m.
On 03/08/2015 12:54 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc@gmail.com>
> # Date 1425243224 28800
> #      Sun Mar 01 12:53:44 2015 -0800
> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
> # Parent  57681bad997779da88778ff95254951c89250441
> ui.paths: filter config options containing "." (BC)
>
> Upcoming patches will enable additional attributes to be defined
> on a per-path basis. This will be done by creating config options
> of the form "path.X" and "path.Y."
>
> This patch teaches the new paths API to assume options containing
> "." are per-path attributes and not valid path names.
>
> This patch is technically backwards incompatible because nothing
> was preventing people from using "." in path names. However, the
> author feels this convention is not widespread enough to warrant
> maintaining backwards compatibility. If backwards compatibility
> is needed, we'll have to employ different functionality for
> defining per-path attributes, such as separate config sections
> per path. An earlier version of this patch series did feature
> separate config sections per path. However, people felt that
> adopting sub-options was a better approach since this is done
> elsewhere (such as with merge tool definition).

Sorry to be late to the party, but I feel like this change is, as is, 
too user-hostile. I'm -certain- there is people out there using 
`foo.bar` paths, and just breaking them seems unfortunate.

Can we get something so that `hg push foo.bar` still works if foo.bar 
exists? (possibly with a warning?) If a someone explicitly ask for 
foo.bar there is a good chance this is not an attributes and that we 
should give them what they asked for.

We should probably also lists them in `hg path` if they do not match any 
known attributes. That would reduce script breakage.
Gregory Szorc - March 11, 2015, 3:56 a.m.
On Mon, Mar 9, 2015 at 8:10 PM, Pierre-Yves David <
pierre-yves.david@ens-lyon.org> wrote:

>
>
> On 03/08/2015 12:54 PM, Gregory Szorc wrote:
>
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc@gmail.com>
>> # Date 1425243224 28800
>> #      Sun Mar 01 12:53:44 2015 -0800
>> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
>> # Parent  57681bad997779da88778ff95254951c89250441
>> ui.paths: filter config options containing "." (BC)
>>
>> Upcoming patches will enable additional attributes to be defined
>> on a per-path basis. This will be done by creating config options
>> of the form "path.X" and "path.Y."
>>
>> This patch teaches the new paths API to assume options containing
>> "." are per-path attributes and not valid path names.
>>
>> This patch is technically backwards incompatible because nothing
>> was preventing people from using "." in path names. However, the
>> author feels this convention is not widespread enough to warrant
>> maintaining backwards compatibility. If backwards compatibility
>> is needed, we'll have to employ different functionality for
>> defining per-path attributes, such as separate config sections
>> per path. An earlier version of this patch series did feature
>> separate config sections per path. However, people felt that
>> adopting sub-options was a better approach since this is done
>> elsewhere (such as with merge tool definition).
>>
>
> Sorry to be late to the party, but I feel like this change is, as is, too
> user-hostile. I'm -certain- there is people out there using `foo.bar`
> paths, and just breaking them seems unfortunate.
>
> Can we get something so that `hg push foo.bar` still works if foo.bar
> exists? (possibly with a warning?) If a someone explicitly ask for foo.bar
> there is a good chance this is not an attributes and that we should give
> them what they asked for.
>
> We should probably also lists them in `hg path` if they do not match any
> known attributes. That would reduce script breakage.


I can make the case that half-support for `foo.bar` paths is even more
hostile than the proposed clean break.

With half-support for `foo.bar` paths, we run the risk of breaking people
with every future Mercurial upgrade. Any new attribute runs the risk of
colliding with a user's path. So now when users upgrade, they are left with
uncertainty as to whether their paths with "." will continue to work. And
it's not just core Mercurial upgrades either. What about extensions
providing their own path attributes? How does the core code know when an
option is a path versus an attribute used by an extension? (I reckon we'll
need to provide a mechanism for extensions to filter out certain
attributes.)

I think a clean, one-time break is better. Users can do a one-time
conversion of paths and be done with it. No surprises in the future. And as
a bonus it makes the code simpler and removes uncertainty about naming
collisions from future attribute additions. We can support the transition
by adding code that detects when the user requests a path with a "." that
matches a config option and abort with a message telling them of the
ambiguous scenario and that they should change their path names.

I think the audience impacted by this is small. I don't think a small
audience warrants additional complexity and ambiguity required by
half-support for paths with ".". FWIW, I'd be more inclined to support
different [path:foo.bar] sections than a hybrid mode: I really don't like
ambiguity in behavior.

Does that change your opinion at all? Anyone else want to weigh in?
Matt Mackall - March 11, 2015, 10:55 p.m.
On Tue, 2015-03-10 at 20:56 -0700, Gregory Szorc wrote:
> On Mon, Mar 9, 2015 at 8:10 PM, Pierre-Yves David <
> pierre-yves.david@ens-lyon.org> wrote:
> 
> >
> >
> > On 03/08/2015 12:54 PM, Gregory Szorc wrote:
> >
> >> # HG changeset patch
> >> # User Gregory Szorc <gregory.szorc@gmail.com>
> >> # Date 1425243224 28800
> >> #      Sun Mar 01 12:53:44 2015 -0800
> >> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
> >> # Parent  57681bad997779da88778ff95254951c89250441
> >> ui.paths: filter config options containing "." (BC)
> >>
> >> Upcoming patches will enable additional attributes to be defined
> >> on a per-path basis. This will be done by creating config options
> >> of the form "path.X" and "path.Y."
> >>
> >> This patch teaches the new paths API to assume options containing
> >> "." are per-path attributes and not valid path names.
> >>
> >> This patch is technically backwards incompatible because nothing
> >> was preventing people from using "." in path names. However, the
> >> author feels this convention is not widespread enough to warrant
> >> maintaining backwards compatibility. If backwards compatibility
> >> is needed, we'll have to employ different functionality for
> >> defining per-path attributes, such as separate config sections
> >> per path. An earlier version of this patch series did feature
> >> separate config sections per path. However, people felt that
> >> adopting sub-options was a better approach since this is done
> >> elsewhere (such as with merge tool definition).
> >>
> >
> > Sorry to be late to the party, but I feel like this change is, as is, too
> > user-hostile. I'm -certain- there is people out there using `foo.bar`
> > paths, and just breaking them seems unfortunate.
> >
> > Can we get something so that `hg push foo.bar` still works if foo.bar
> > exists? (possibly with a warning?) If a someone explicitly ask for foo.bar
> > there is a good chance this is not an attributes and that we should give
> > them what they asked for.
> >
> > We should probably also lists them in `hg path` if they do not match any
> > known attributes. That would reduce script breakage.
> 
> 
> I can make the case that half-support for `foo.bar` paths is even more
> hostile than the proposed clean break.

I agree that the odds of people having foo.bar paths is probably 100%:
it is after all how DNS names are structured. Unfortunately it's also
how our config namespace is structured.

> I think a clean, one-time break is better.

I greatly prefer zero-time breaks, but I don't have a great alternative
suggestion. We do have a bit of precedent in the [auth] section though.
Perhaps we can do:

[paths]
old.style = some/path
new.style.path = some/other/pass
new.style.option = foo
bogus.option = foo

Here, hg paths would list:

old.style
new.style
bogus.option

(..and we'd also change clone to make the default path setting
"default.path".)
Pierre-Yves David - March 13, 2015, 10:56 p.m.
On 03/11/2015 03:55 PM, Matt Mackall wrote:
> On Tue, 2015-03-10 at 20:56 -0700, Gregory Szorc wrote:
>> On Mon, Mar 9, 2015 at 8:10 PM, Pierre-Yves David <
>> pierre-yves.david@ens-lyon.org> wrote:
>>
>>>
>>>
>>> On 03/08/2015 12:54 PM, Gregory Szorc wrote:
>>>
>>>> # HG changeset patch
>>>> # User Gregory Szorc <gregory.szorc@gmail.com>
>>>> # Date 1425243224 28800
>>>> #      Sun Mar 01 12:53:44 2015 -0800
>>>> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
>>>> # Parent  57681bad997779da88778ff95254951c89250441
>>>> ui.paths: filter config options containing "." (BC)
>>>>
>>>> Upcoming patches will enable additional attributes to be defined
>>>> on a per-path basis. This will be done by creating config options
>>>> of the form "path.X" and "path.Y."
>>>>
>>>> This patch teaches the new paths API to assume options containing
>>>> "." are per-path attributes and not valid path names.
>>>>
>>>> This patch is technically backwards incompatible because nothing
>>>> was preventing people from using "." in path names. However, the
>>>> author feels this convention is not widespread enough to warrant
>>>> maintaining backwards compatibility. If backwards compatibility
>>>> is needed, we'll have to employ different functionality for
>>>> defining per-path attributes, such as separate config sections
>>>> per path. An earlier version of this patch series did feature
>>>> separate config sections per path. However, people felt that
>>>> adopting sub-options was a better approach since this is done
>>>> elsewhere (such as with merge tool definition).
>>>>
>>>
>>> Sorry to be late to the party, but I feel like this change is, as is, too
>>> user-hostile. I'm -certain- there is people out there using `foo.bar`
>>> paths, and just breaking them seems unfortunate.
>>>
>>> Can we get something so that `hg push foo.bar` still works if foo.bar
>>> exists? (possibly with a warning?) If a someone explicitly ask for foo.bar
>>> there is a good chance this is not an attributes and that we should give
>>> them what they asked for.
>>>
>>> We should probably also lists them in `hg path` if they do not match any
>>> known attributes. That would reduce script breakage.
>>
>>
>> I can make the case that half-support for `foo.bar` paths is even more
>> hostile than the proposed clean break.
>
> I agree that the odds of people having foo.bar paths is probably 100%:
> it is after all how DNS names are structured. Unfortunately it's also
> how our config namespace is structured.
>
>> I think a clean, one-time break is better.
>
> I greatly prefer zero-time breaks, but I don't have a great alternative
> suggestion. We do have a bit of precedent in the [auth] section though.
> Perhaps we can do:
>
> [paths]
> old.style = some/path
> new.style.path = some/other/pass
> new.style.option = foo
> bogus.option = foo

I'm a bit puzzled by the new.style.path here (I'll change it to 
`newstyle.path` to clarify my puzzling.)

I think we should keep the "basicname" value as the path, using option 
only for other special values like "push-path, aliasname, pushed//pulled 
revset, etc). This would keep existing config valid and consistent on 
the long run.

Matt, was this just a random example or do you forsee such massive 
switch in config option.

> Here, hg paths would list:
>
> old.style
> new.style
> bogus.option

+1 for style seeing dotted path as valid if they have no "parent" one.

Should we also try to resolve any path explicitly request if it exists ?

> (..and we'd also change clone to make the default path setting
> "default.path".)

This makes me suspect Matt is plotting a massive revolution.
Matt Mackall - March 14, 2015, 9:33 p.m.
On Fri, 2015-03-13 at 15:56 -0700, Pierre-Yves David wrote:
> 
> On 03/11/2015 03:55 PM, Matt Mackall wrote:
> > On Tue, 2015-03-10 at 20:56 -0700, Gregory Szorc wrote:
> >> On Mon, Mar 9, 2015 at 8:10 PM, Pierre-Yves David <
> >> pierre-yves.david@ens-lyon.org> wrote:
> >>
> >>>
> >>>
> >>> On 03/08/2015 12:54 PM, Gregory Szorc wrote:
> >>>
> >>>> # HG changeset patch
> >>>> # User Gregory Szorc <gregory.szorc@gmail.com>
> >>>> # Date 1425243224 28800
> >>>> #      Sun Mar 01 12:53:44 2015 -0800
> >>>> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
> >>>> # Parent  57681bad997779da88778ff95254951c89250441
> >>>> ui.paths: filter config options containing "." (BC)
> >>>>
> >>>> Upcoming patches will enable additional attributes to be defined
> >>>> on a per-path basis. This will be done by creating config options
> >>>> of the form "path.X" and "path.Y."
> >>>>
> >>>> This patch teaches the new paths API to assume options containing
> >>>> "." are per-path attributes and not valid path names.
> >>>>
> >>>> This patch is technically backwards incompatible because nothing
> >>>> was preventing people from using "." in path names. However, the
> >>>> author feels this convention is not widespread enough to warrant
> >>>> maintaining backwards compatibility. If backwards compatibility
> >>>> is needed, we'll have to employ different functionality for
> >>>> defining per-path attributes, such as separate config sections
> >>>> per path. An earlier version of this patch series did feature
> >>>> separate config sections per path. However, people felt that
> >>>> adopting sub-options was a better approach since this is done
> >>>> elsewhere (such as with merge tool definition).
> >>>>
> >>>
> >>> Sorry to be late to the party, but I feel like this change is, as is, too
> >>> user-hostile. I'm -certain- there is people out there using `foo.bar`
> >>> paths, and just breaking them seems unfortunate.
> >>>
> >>> Can we get something so that `hg push foo.bar` still works if foo.bar
> >>> exists? (possibly with a warning?) If a someone explicitly ask for foo.bar
> >>> there is a good chance this is not an attributes and that we should give
> >>> them what they asked for.
> >>>
> >>> We should probably also lists them in `hg path` if they do not match any
> >>> known attributes. That would reduce script breakage.
> >>
> >>
> >> I can make the case that half-support for `foo.bar` paths is even more
> >> hostile than the proposed clean break.
> >
> > I agree that the odds of people having foo.bar paths is probably 100%:
> > it is after all how DNS names are structured. Unfortunately it's also
> > how our config namespace is structured.
> >
> >> I think a clean, one-time break is better.
> >
> > I greatly prefer zero-time breaks, but I don't have a great alternative
> > suggestion. We do have a bit of precedent in the [auth] section though.
> > Perhaps we can do:
> >
> > [paths]
> > old.style = some/path
> > new.style.path = some/other/pass
> > new.style.option = foo
> > bogus.option = foo
> 
> I'm a bit puzzled by the new.style.path here (I'll change it to 
> `newstyle.path` to clarify my puzzling.)

Then you've 100% missed the point. This idea is all about dots and how
we tell what they mean.
Gregory Szorc - March 15, 2015, 5:18 a.m.
On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <mpm@selenic.com> wrote:

> I agree that the odds of people having foo.bar paths is probably 100%:
> it is after all how DNS names are structured. Unfortunately it's also
> how our config namespace is structured.
>

I think it is important to distinguish between option names, option values,
and command line arguments.

For option values and command line arguments, absolutely we'll have periods
because of hostnames. However, I believe our logic there is to first
attempt to parse those values as URLs, then fall back to a filesystem-local
path if a scheme isn't present. (Follow-up idea: have Mercurial store URLs
in more situations because bare strings are more ambiguous.)

If we limit discussion to option values, I'm still not convinced supporting
periods is important.


> > I think a clean, one-time break is better.
>
> I greatly prefer zero-time breaks, but I don't have a great alternative
> suggestion. We do have a bit of precedent in the [auth] section though.
> Perhaps we can do:
>
> [paths]
> old.style = some/path
> new.style.path = some/other/pass
> new.style.option = foo
> bogus.option = foo
>
> Here, hg paths would list:
>
> old.style
> new.style
> bogus.option
>
> (..and we'd also change clone to make the default path setting
> "default.path".)
>

This is an interesting idea. I like how it avoids ambiguity between whether
an entry is a path or isn't. However, it still has concerns:

* Long-term Mercurial users now have to convert to a new config style to
use advanced options.
* Potential for collision between user-defined path names and per-path
options.

I imagine a user will see they can add ".pushrev" to a path and produce a
snippet like:

[paths]
central = https://hg.mozilla.org/mozilla-central
central.pushrev = .

Without the ".path", this situation is ambiguous. Do we then have to
examine common option prefixes and do some kind of disambiguation to figure
out the user's intent? What about something like this:

[paths]
repo.prod = https://prod.hg.example.com/repo
repo.prod.pushrev = .
repo.dev = https://dev.hg.example.com/repo

I still think unsupported periods in path names is looking pretty
reasonable. So does separate [path.x] sections.
Matt Mackall - March 15, 2015, 7:55 p.m.
On Sat, 2015-03-14 at 22:18 -0700, Gregory Szorc wrote:
> On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <mpm@selenic.com> wrote:
> 
> > I agree that the odds of people having foo.bar paths is probably 100%:
> > it is after all how DNS names are structured. Unfortunately it's also
> > how our config namespace is structured.
> >
> 
> I think it is important to distinguish between option names, option values,
> and command line arguments.
> 
> For option values and command line arguments, absolutely we'll have periods
> because of hostnames. However, I believe our logic there is to first
> attempt to parse those values as URLs, then fall back to a filesystem-local
> path if a scheme isn't present. (Follow-up idea: have Mercurial store URLs
> in more situations because bare strings are more ambiguous.)

$ hg push selenic.com
pushing to selenic.com
abort: repository selenic.com not found!

No, we treat bare hostnames as local paths.

But I think people will actually have hostname-like entries as path
_keys_, not values (where they won't actually work). And then use those
path keys on the command line. For instance, I can imagine a project
split between foo.org (open source) and foo.com (with commercial bits)
and someone having both URLs in their ~/.hgrc. Or perhaps the domain is
integral to the verbal identity like "healthcare.gov" (you'd never refer
to it as just "healthcare" or "healthcaregov"). Picture a web design
shop that's deploying to its dozens of clients' sites by domain name... 

> If we limit discussion to option values, I'm still not convinced supporting
> periods is important.
> 
> 
> > > I think a clean, one-time break is better.
> >
> > I greatly prefer zero-time breaks, but I don't have a great alternative
> > suggestion. We do have a bit of precedent in the [auth] section though.
> > Perhaps we can do:
> >
> > [paths]
> > old.style = some/path
> > new.style.path = some/other/pass
> > new.style.option = foo
> > bogus.option = foo
> >
> > Here, hg paths would list:
> >
> > old.style
> > new.style
> > bogus.option
> >
> > (..and we'd also change clone to make the default path setting
> > "default.path".)
> >
> 
> This is an interesting idea. I like how it avoids ambiguity between whether
> an entry is a path or isn't. However, it still has concerns:
> 
> * Long-term Mercurial users now have to convert to a new config style to
> use advanced options.

Yeah, but I think that's pretty minor.

> * Potential for collision between user-defined path names and per-path
> options.

I think the potential only exists for paths of the form "foo.bar.path",
which signals "hey, we have a path with options named foo.bar". So if
you happen to want to name something with a ".path" suffix, you'll now
have to name it ".path.path". Not perfect, but not fatal.

> I imagine a user will see they can add ".pushrev" to a path and produce a
> snippet like:
> 
> [paths]
> central = https://hg.mozilla.org/mozilla-central
> central.pushrev = .
> 
> Without the ".path", this situation is ambiguous. Do we then have to
> examine common option prefixes and do some kind of disambiguation to figure
> out the user's intent?

Yeah, this won't work in my scheme, it'll define two paths. A path X is
only newstyle with options if X.path is defined. So any examples of
central.pushrev would need to include central.path.

>  What about something like this:
> 
> [paths]
> repo.prod = https://prod.hg.example.com/repo
> repo.prod.pushrev = .
> repo.dev = https://dev.hg.example.com/repo
> 
> I still think unsupported periods in path names is looking pretty
> reasonable. So does separate [path.x] sections.

What's unsupported periods again? That's no dots in path keys?

I don't think that's going to work. I don't know that path.x sections
work either, because the config format actually already treats dots as
hierarchy separators and [foo] is just a special case for the tree top
level. In other words [foo]bar.x and [foo.bar]x are both aliases for
foo.bar.x.

Perhaps we can use a horrible separator. I don't think we can use #
because it's already used for branches. Let's say it's "+"[1]. Then we
can have:

[paths]
repo = https://...
repo+pushrev = .

This is kinda ok because it suggests adding something on. Another
possibility is "--", which lets us suggest a relation to the
corresponding command-line options.

[1] Not perfect, but Windows filesystems are hostile to it.
Adrian Buehlmann - March 15, 2015, 8:50 p.m.
On 2015-03-15 20:55, Matt Mackall wrote:
> Perhaps we can use a horrible separator. I don't think we can use #
> because it's already used for branches. Let's say it's "+"[1]. Then we
> can have:
> 
> [paths]
> repo = https://...
> repo+pushrev = .
> 
> This is kinda ok because it suggests adding something on. Another
> possibility is "--", which lets us suggest a relation to the
> corresponding command-line options.
> 
> [1] Not perfect, but Windows filesystems are hostile to it.

Not sure what you are referring to exactly, but '+' is way less
"hostile" than '.' in filenames on Windows. Just in case...
Matt Mackall - March 15, 2015, 9:46 p.m.
On Sun, 2015-03-15 at 21:50 +0100, Adrian Buehlmann wrote:
> On 2015-03-15 20:55, Matt Mackall wrote:
> > Perhaps we can use a horrible separator. I don't think we can use #
> > because it's already used for branches. Let's say it's "+"[1]. Then we
> > can have:
> > 
> > [paths]
> > repo = https://...
> > repo+pushrev = .
> > 
> > This is kinda ok because it suggests adding something on. Another
> > possibility is "--", which lets us suggest a relation to the
> > corresponding command-line options.
> > 
> > [1] Not perfect, but Windows filesystems are hostile to it.
> 
> Not sure what you are referring to exactly, but '+' is way less
> "hostile" than '.' in filenames on Windows. Just in case...

Showing my age, I guess. I used DOS 1.0 through NT 3.1 where "+" was
problematic, then switched to Linux. The problem with "+" (can't be used
with FAT filesystem) went away with the introduction of VFAT longnames
in Windows 95.
Gregory Szorc - March 17, 2015, 4:04 a.m.
On Sun, Mar 15, 2015 at 12:55 PM, Matt Mackall <mpm@selenic.com> wrote:

> On Sat, 2015-03-14 at 22:18 -0700, Gregory Szorc wrote:
> > On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <mpm@selenic.com> wrote:
> >
> > > I agree that the odds of people having foo.bar paths is probably 100%:
> > > it is after all how DNS names are structured. Unfortunately it's also
> > > how our config namespace is structured.
> > >
> >
> > I think it is important to distinguish between option names, option
> values,
> > and command line arguments.
> >
> > For option values and command line arguments, absolutely we'll have
> periods
> > because of hostnames. However, I believe our logic there is to first
> > attempt to parse those values as URLs, then fall back to a
> filesystem-local
> > path if a scheme isn't present. (Follow-up idea: have Mercurial store
> URLs
> > in more situations because bare strings are more ambiguous.)
>
> $ hg push selenic.com
> pushing to selenic.com
> abort: repository selenic.com not found!
>
> No, we treat bare hostnames as local paths.
>
> But I think people will actually have hostname-like entries as path
> _keys_, not values (where they won't actually work). And then use those
> path keys on the command line. For instance, I can imagine a project
> split between foo.org (open source) and foo.com (with commercial bits)
> and someone having both URLs in their ~/.hgrc. Or perhaps the domain is
> integral to the verbal identity like "healthcare.gov" (you'd never refer
> to it as just "healthcare" or "healthcaregov"). Picture a web design
> shop that's deploying to its dozens of clients' sites by domain name...
>
> > If we limit discussion to option values, I'm still not convinced
> supporting
> > periods is important.
> >
> >
> > > > I think a clean, one-time break is better.
> > >
> > > I greatly prefer zero-time breaks, but I don't have a great alternative
> > > suggestion. We do have a bit of precedent in the [auth] section though.
> > > Perhaps we can do:
> > >
> > > [paths]
> > > old.style = some/path
> > > new.style.path = some/other/pass
> > > new.style.option = foo
> > > bogus.option = foo
> > >
> > > Here, hg paths would list:
> > >
> > > old.style
> > > new.style
> > > bogus.option
> > >
> > > (..and we'd also change clone to make the default path setting
> > > "default.path".)
> > >
> >
> > This is an interesting idea. I like how it avoids ambiguity between
> whether
> > an entry is a path or isn't. However, it still has concerns:
> >
> > * Long-term Mercurial users now have to convert to a new config style to
> > use advanced options.
>
> Yeah, but I think that's pretty minor.
>
> > * Potential for collision between user-defined path names and per-path
> > options.
>
> I think the potential only exists for paths of the form "foo.bar.path",
> which signals "hey, we have a path with options named foo.bar". So if
> you happen to want to name something with a ".path" suffix, you'll now
> have to name it ".path.path". Not perfect, but not fatal.
>
> > I imagine a user will see they can add ".pushrev" to a path and produce a
> > snippet like:
> >
> > [paths]
> > central = https://hg.mozilla.org/mozilla-central
> > central.pushrev = .
> >
> > Without the ".path", this situation is ambiguous. Do we then have to
> > examine common option prefixes and do some kind of disambiguation to
> figure
> > out the user's intent?
>
> Yeah, this won't work in my scheme, it'll define two paths. A path X is
> only newstyle with options if X.path is defined. So any examples of
> central.pushrev would need to include central.path.
>
> >  What about something like this:
> >
> > [paths]
> > repo.prod = https://prod.hg.example.com/repo
> > repo.prod.pushrev = .
> > repo.dev = https://dev.hg.example.com/repo
> >
> > I still think unsupported periods in path names is looking pretty
> > reasonable. So does separate [path.x] sections.
>
> What's unsupported periods again? That's no dots in path keys?
>

Dots in path keys.


> I don't think that's going to work. I don't know that path.x sections
> work either, because the config format actually already treats dots as
> hierarchy separators and [foo] is just a special case for the tree top
> level. In other words [foo]bar.x and [foo.bar]x are both aliases for
> foo.bar.x.
>

I'm not so sure about that. I *think* config.config is preserving all
content in [SECTION]. I don't see anywhere where dots are getting collapsed.

(Pdb) import config
(Pdb) conf = config.config()
(Pdb) conf.parse('test', '[path.foo]\nbar = True')
(Pdb) pp conf._data
{'path.foo': {'bar': 'True'}}

I think passing the sections list down to the ui.paths constructor will
work. I did something similar in the first version of this patch series (I
was foolishly using ":" as the delimiter - "[path:foo]") and it seemed to
work fine.
Ryan McElroy - March 22, 2015, 1:19 a.m.
On 3/16/2015 9:04 PM, Gregory Szorc wrote:
> On Sun, Mar 15, 2015 at 12:55 PM, Matt Mackall <mpm@selenic.com 
> <mailto:mpm@selenic.com>> wrote:
>
>     On Sat, 2015-03-14 at 22:18 -0700, Gregory Szorc wrote:
>     > On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <mpm@selenic.com
>     <mailto:mpm@selenic.com>> wrote:
>     >
>     > > I agree that the odds of people having foo.bar paths is
>     probably 100%:
>     > > it is after all how DNS names are structured. Unfortunately
>     it's also
>     > > how our config namespace is structured.
>     > >
>     >
>     > I think it is important to distinguish between option names,
>     option values,
>     > and command line arguments.
>     >
>     > For option values and command line arguments, absolutely we'll
>     have periods
>     > because of hostnames. However, I believe our logic there is to first
>     > attempt to parse those values as URLs, then fall back to a
>     filesystem-local
>     > path if a scheme isn't present. (Follow-up idea: have Mercurial
>     store URLs
>     > in more situations because bare strings are more ambiguous.)
>
>     $ hg push selenic.com <http://selenic.com>
>     pushing to selenic.com <http://selenic.com>
>     abort: repository selenic.com <http://selenic.com> not found!
>
>     No, we treat bare hostnames as local paths.
>
>     But I think people will actually have hostname-like entries as path
>     _keys_, not values (where they won't actually work). And then use
>     those
>     path keys on the command line. For instance, I can imagine a project
>     split between foo.org <http://foo.org> (open source) and foo.com
>     <http://foo.com> (with commercial bits)
>     and someone having both URLs in their ~/.hgrc. Or perhaps the
>     domain is
>     integral to the verbal identity like "healthcare.gov
>     <http://healthcare.gov>" (you'd never refer
>     to it as just "healthcare" or "healthcaregov"). Picture a web design
>     shop that's deploying to its dozens of clients' sites by domain
>     name...
>
>     > If we limit discussion to option values, I'm still not convinced
>     supporting
>     > periods is important.
>     >
>     >
>     > > > I think a clean, one-time break is better.
>     > >
>     > > I greatly prefer zero-time breaks, but I don't have a great
>     alternative
>     > > suggestion. We do have a bit of precedent in the [auth]
>     section though.
>     > > Perhaps we can do:
>     > >
>     > > [paths]
>     > > old.style = some/path
>     > > new.style.path = some/other/pass
>     > > new.style.option = foo
>     > > bogus.option = foo
>     > >
>     > > Here, hg paths would list:
>     > >
>     > > old.style
>     > > new.style
>     > > bogus.option
>     > >
>     > > (..and we'd also change clone to make the default path setting
>     > > "default.path".)
>     > >
>     >
>     > This is an interesting idea. I like how it avoids ambiguity
>     between whether
>     > an entry is a path or isn't. However, it still has concerns:
>     >
>     > * Long-term Mercurial users now have to convert to a new config
>     style to
>     > use advanced options.
>
>     Yeah, but I think that's pretty minor.
>
>     > * Potential for collision between user-defined path names and
>     per-path
>     > options.
>
>     I think the potential only exists for paths of the form
>     "foo.bar.path",
>     which signals "hey, we have a path with options named foo.bar". So if
>     you happen to want to name something with a ".path" suffix, you'll now
>     have to name it ".path.path". Not perfect, but not fatal.
>
>     > I imagine a user will see they can add ".pushrev" to a path and
>     produce a
>     > snippet like:
>     >
>     > [paths]
>     > central = https://hg.mozilla.org/mozilla-central
>     > central.pushrev = .
>     >
>     > Without the ".path", this situation is ambiguous. Do we then have to
>     > examine common option prefixes and do some kind of
>     disambiguation to figure
>     > out the user's intent?
>
>     Yeah, this won't work in my scheme, it'll define two paths. A path
>     X is
>     only newstyle with options if X.path is defined. So any examples of
>     central.pushrev would need to include central.path.
>
>     >  What about something like this:
>     >
>     > [paths]
>     > repo.prod = https://prod.hg.example.com/repo
>     > repo.prod.pushrev = .
>     > repo.dev = https://dev.hg.example.com/repo
>     >
>     > I still think unsupported periods in path names is looking pretty
>     > reasonable. So does separate [path.x] sections.
>
>     What's unsupported periods again? That's no dots in path keys?
>
>
> Dots in path keys.
>
>     I don't think that's going to work. I don't know that path.x sections
>     work either, because the config format actually already treats dots as
>     hierarchy separators and [foo] is just a special case for the tree top
>     level. In other words [foo]bar.x and [foo.bar]x are both aliases for
>     foo.bar.x.
>
>
> I'm not so sure about that. I *think* config.config is preserving all 
> content in [SECTION]. I don't see anywhere where dots are getting 
> collapsed.
>
> (Pdb) import config
> (Pdb) conf = config.config()
> (Pdb) conf.parse('test', '[path.foo]\nbar = True')
> (Pdb) pp conf._data
> {'path.foo': {'bar': 'True'}}
>
> I think passing the sections list down to the ui.paths constructor 
> will work. I did something similar in the first version of this patch 
> series (I was foolishly using ":" as the delimiter - "[path:foo]") and 
> it seemed to work fine.
>

Kind of late to the party here, but it didn't seem that this had been 
decided yet so I thought I'd throw out a thought I had while reading 
this discussion:

Add a new section, called [uris]. In it, we can do it in an "enhanced" 
way. Probably we would enforce more rules on the URIs -- eg, make them 
unambiguous and fully qualified so "mirror" style clones (a future 
feature) would be able to copy them and know they point to the same 
thing (this is just an idea, a real implementation would figure out what 
the "right" rules are).

[uris]
default.uri = http://smf.io/hgremotenames
default.pushrev = .
default.newoption = foo

Thoughts? If I missed the memo and this is already decided in a 
different direction, I'm happy to be informed of that as well.

~Ryan
Gregory Szorc - March 23, 2015, 4:27 p.m.
On Sat, Mar 21, 2015 at 6:19 PM, Ryan McElroy <rm@fb.com> wrote:

>  On 3/16/2015 9:04 PM, Gregory Szorc wrote:
>
> On Sun, Mar 15, 2015 at 12:55 PM, Matt Mackall <mpm@selenic.com> wrote:
>
>> On Sat, 2015-03-14 at 22:18 -0700, Gregory Szorc wrote:
>> > On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <mpm@selenic.com> wrote:
>> >
>> > > I agree that the odds of people having foo.bar paths is probably 100%:
>> > > it is after all how DNS names are structured. Unfortunately it's also
>> > > how our config namespace is structured.
>> > >
>> >
>> > I think it is important to distinguish between option names, option
>> values,
>> > and command line arguments.
>> >
>> > For option values and command line arguments, absolutely we'll have
>> periods
>> > because of hostnames. However, I believe our logic there is to first
>> > attempt to parse those values as URLs, then fall back to a
>> filesystem-local
>> > path if a scheme isn't present. (Follow-up idea: have Mercurial store
>> URLs
>> > in more situations because bare strings are more ambiguous.)
>>
>> $ hg push selenic.com
>> pushing to selenic.com
>> abort: repository selenic.com not found!
>>
>> No, we treat bare hostnames as local paths.
>>
>> But I think people will actually have hostname-like entries as path
>> _keys_, not values (where they won't actually work). And then use those
>> path keys on the command line. For instance, I can imagine a project
>> split between foo.org (open source) and foo.com (with commercial bits)
>> and someone having both URLs in their ~/.hgrc. Or perhaps the domain is
>> integral to the verbal identity like "healthcare.gov" (you'd never refer
>> to it as just "healthcare" or "healthcaregov"). Picture a web design
>> shop that's deploying to its dozens of clients' sites by domain name...
>>
>> > If we limit discussion to option values, I'm still not convinced
>> supporting
>> > periods is important.
>> >
>> >
>> > > > I think a clean, one-time break is better.
>> > >
>> > > I greatly prefer zero-time breaks, but I don't have a great
>> alternative
>> > > suggestion. We do have a bit of precedent in the [auth] section
>> though.
>> > > Perhaps we can do:
>> > >
>> > > [paths]
>> > > old.style = some/path
>> > > new.style.path = some/other/pass
>> > > new.style.option = foo
>> > > bogus.option = foo
>> > >
>> > > Here, hg paths would list:
>> > >
>> > > old.style
>> > > new.style
>> > > bogus.option
>> > >
>> > > (..and we'd also change clone to make the default path setting
>> > > "default.path".)
>> > >
>> >
>> > This is an interesting idea. I like how it avoids ambiguity between
>> whether
>> > an entry is a path or isn't. However, it still has concerns:
>> >
>> > * Long-term Mercurial users now have to convert to a new config style to
>> > use advanced options.
>>
>> Yeah, but I think that's pretty minor.
>>
>> > * Potential for collision between user-defined path names and per-path
>> > options.
>>
>> I think the potential only exists for paths of the form "foo.bar.path",
>> which signals "hey, we have a path with options named foo.bar". So if
>> you happen to want to name something with a ".path" suffix, you'll now
>> have to name it ".path.path". Not perfect, but not fatal.
>>
>> > I imagine a user will see they can add ".pushrev" to a path and produce
>> a
>> > snippet like:
>> >
>> > [paths]
>> > central = https://hg.mozilla.org/mozilla-central
>> > central.pushrev = .
>> >
>> > Without the ".path", this situation is ambiguous. Do we then have to
>> > examine common option prefixes and do some kind of disambiguation to
>> figure
>> > out the user's intent?
>>
>> Yeah, this won't work in my scheme, it'll define two paths. A path X is
>> only newstyle with options if X.path is defined. So any examples of
>> central.pushrev would need to include central.path.
>>
>> >  What about something like this:
>> >
>> > [paths]
>> > repo.prod = https://prod.hg.example.com/repo
>> > repo.prod.pushrev = .
>> > repo.dev = https://dev.hg.example.com/repo
>> >
>> > I still think unsupported periods in path names is looking pretty
>> > reasonable. So does separate [path.x] sections.
>>
>> What's unsupported periods again? That's no dots in path keys?
>>
>
>  Dots in path keys.
>
>
>> I don't think that's going to work. I don't know that path.x sections
>> work either, because the config format actually already treats dots as
>> hierarchy separators and [foo] is just a special case for the tree top
>> level. In other words [foo]bar.x and [foo.bar]x are both aliases for
>> foo.bar.x.
>>
>
>  I'm not so sure about that. I *think* config.config is preserving all
> content in [SECTION]. I don't see anywhere where dots are getting collapsed.
>
>  (Pdb) import config
> (Pdb) conf = config.config()
> (Pdb) conf.parse('test', '[path.foo]\nbar = True')
> (Pdb) pp conf._data
> {'path.foo': {'bar': 'True'}}
>
>  I think passing the sections list down to the ui.paths constructor will
> work. I did something similar in the first version of this patch series (I
> was foolishly using ":" as the delimiter - "[path:foo]") and it seemed to
> work fine.
>
>
> Kind of late to the party here, but it didn't seem that this had been
> decided yet so I thought I'd throw out a thought I had while reading this
> discussion:
>
> Add a new section, called [uris]. In it, we can do it in an "enhanced"
> way. Probably we would enforce more rules on the URIs -- eg, make them
> unambiguous and fully qualified so "mirror" style clones (a future feature)
> would be able to copy them and know they point to the same thing (this is
> just an idea, a real implementation would figure out what the "right" rules
> are).
>
> [uris]
> default.uri = http://smf.io/hgremotenames
> default.pushrev = .
> default.newoption = foo
>
> Thoughts? If I missed the memo and this is already decided in a different
> direction, I'm happy to be informed of that as well.
>

Aside from the potential confusion around multiple sections (which we may
have anyway if we go with [path.X]), I like it! As a bonus, this is
relatively simple to implement (just union entries inside the new "paths"
API).

As a bikeshed, should we consider "remotes" instead of "uris?" That jives
with "remotenames." It's also very Git-like. But I'm not sure if that's
good or bad.
Ryan McElroy - March 23, 2015, 4:42 p.m.
On 3/23/2015 9:27 AM, Gregory Szorc wrote:
>
>     On Sat, Mar 21, 2015 at 6:19 PM, Ryan McElroy <rm@fb.com
>     <mailto:rm@fb.com>> wrote:
>
>     Kind of late to the party here, but it didn't seem that this had
>     been decided yet so I thought I'd throw out a thought I had while
>     reading this discussion:
>
>     Add a new section, called [uris]. In it, we can do it in an
>     "enhanced" way. Probably we would enforce more rules on the URIs
>     -- eg, make them unambiguous and fully qualified so "mirror" style
>     clones (a future feature) would be able to copy them and know they
>     point to the same thing (this is just an idea, a real
>     implementation would figure out what the "right" rules are).
>
>     [uris]
>     default.uri = http://smf.io/hgremotenames
>     default.pushrev = .
>     default.newoption = foo
>
>     Thoughts? If I missed the memo and this is already decided in a
>     different direction, I'm happy to be informed of that as well.
>
>
> Aside from the potential confusion around multiple sections (which we 
> may have anyway if we go with [path.X]), I like it! As a bonus, this 
> is relatively simple to implement (just union entries inside the new 
> "paths" API).
>
> As a bikeshed, should we consider "remotes" instead of "uris?" That 
> jives with "remotenames." It's also very Git-like. But I'm not sure if 
> that's good or bad.

I chatted with @pyd on the Caltrain on Saturday about this before I sent 
the email. The possibility of "remotes" came up but the peer might be 
"local" as well (eg, another dir on your machine made me not fall in 
love with that name, but I'm not against it either). But since we're 
bikeshedding, let me throw out a few more  possibilities with commentary:

[peers]   # I really like this one, it's very mercurial-y, I just 
realized this might be a good name when writing my response above
[newpaths]  # Obviously related to paths
[paths2] # shorter, same as above

~Ryan
Gilles Moris - March 24, 2015, 6:38 a.m.
Le 23/03/2015 17:42, Ryan McElroy a écrit :
>
> I chatted with @pyd on the Caltrain on Saturday about this before I 
> sent the email. The possibility of "remotes" came up but the peer 
> might be "local" as well (eg, another dir on your machine made me not 
> fall in love with that name, but I'm not against it either). But since 
> we're bikeshedding, let me throw out a few more  possibilities with 
> commentary:
>
> [peers]   # I really like this one, it's very mercurial-y, I just 
> realized this might be a good name when writing my response above
> [newpaths]  # Obviously related to paths
> [paths2] # shorter, same as above
>
> ~Ryan

Then let me throw:
[pathsext]
or
[richpaths]

new is only new until it is superseded by something even newer.

Regards.
Gilles.

Patch

diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -941,8 +941,14 @@  class paths(dict):
         for name, loc in ui.configitems('paths'):
             # No location is the same as not existing.
             if not loc:
                 continue
+
+            # Options with "." are reserved for future use to define
+            # per-path attributes.
+            if '.' in name:
+                continue
+
             self[name] = path(name, rawloc=loc)
 
     def getpath(self, name, default=None):
         """Return a ``path`` for the specified name, falling back to a default.
diff --git a/tests/test-paths.t b/tests/test-paths.t
--- a/tests/test-paths.t
+++ b/tests/test-paths.t
@@ -62,4 +62,19 @@ 
   $ hg -q id
   000000000000
 
   $ cd ..
+
+Options with "." are reserved for per-path settings
+
+  $ cat >> $HGRCPATH << EOF
+  > [paths]
+  > default = http://hg.example.com/
+  > default.foo = True
+  > other = http://hg2.example.com/
+  > other.irrelevant = "some value"
+  > EOF
+  $ hg init paths-with-options
+  $ hg -R paths-with-options paths
+  default = http://hg.example.com/
+  gpath1 = http://hg.example.com/
+  other = http://hg2.example.com/