On Thu, 2018-03-15 at 19:57 -0400, langdon wrote: > On 03/15/2018 04:31 PM, Simo Sorce wrote: > > On Thu, 2018-03-15 at 14:06 -0400, Randy Barlow wrote: > > > On 03/15/2018 12:28 PM, Chuck Anderson wrote: > > > > : doesn't work very well in filenames due to it being a pathname separator in some filesystems among other things. > > > > > > It sounds like this breaks a great deal of tooling. Can we reconsider > > > switching away from - separators in modules? Is allowing streams to have > > > -'s in them important enough to break so many tools? > > > > I vote for using ⨊ as the separator, makes things easier :-) > > > > Simo. > > > > kidding aside, we are trying to get metadata forced in to the name > "field"[1] in to proper metadata fields rather than just mangling the > names. As a result, we end up with more fields and we don't have to > guess what they are based on conventions. > > I also am not sure why we wouldn't want to have hyphens in the names of > modules. For example, a package for "react-native". If you are trying to parse a delimited string, you can cope with either the *first* or *last* field also being allowed to contain the delimiter. This is how it works for RPM NEVRAs: name can contain a -, but epoch, version, release and arch cannot. This allows reliable parsing because you know any 'extra' -s must be part of the name; practically speaking, as the subject of the thread suggests, you can just do a .rsplit() (or equivalent in your language of choice) to get the fields. So: there would be no problem with - in the *name* of the modules, so long as that's the first field, which apparently it is. The problem is if you allow the delimiter in *both* the first and last fields, or in *any other field besides the first and the last*. As soon as you do that, parsing is impossible. This is the issue with module names, as Patrick pointed out: they allow - in the stream, which is the *second* field. As soon as you allow this, reliably parsing the name components out of the whole name becomes impossible. Yes, you can say 'just don't parse strings, go ask a service instead', but parsing strings is sometimes by a long way the most convenient way to do things, and I really can't see how allowing the delimiter character to appear in one of the field names is a *bigger* win than allowing the components to be reliably parsed from the overall name. (I have extensive experience with this field, thanks to dealing with RPM names, image filenames, *and* Pungi compose IDs (oh God, don't make me break out my compose ID parser as an example), and at this point I'd like to designate a special circle of hell for people who do this sort of thing. :>) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
