[gentoo-dev] A more natural (human-friendly) syntax for dependencies

[gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Hello,

The current dependency syntax:

  [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]

suffers a few problems:


1. It is not really human-friendly.

People don't say things like:

  I need newer than monkey-1.2.

They say instead:

  I need monkey, newer than version 1.2.


2. With long package names and versions, it becomes hard-to-read.

Consider the following:

  >=dev-foo/bar-very-long-my-name-is-4-beta-17

Where does the version number start? And yes, this is a valid package
name to our rules.


3. Some potentially colliding package names are disallowed.

A package name can't end up with something looking like version. Thus,
if upstream names package:

  frobnicator-11

We need to rename it in the tree, effectively losing the ability to
follow upstream naming and introducing a bunch of unnecessary MY_P, S
variables.


4. Adding, removing and changing versions is not friendly at all.

Consider the following dep:

  >=dev-foo/bar-bas-bat-11.2.4_alpha

Now, you want to bump the dep to 11.3. You need to find the version
number, and modify it. Depending on the configuration, ^w is going to
eat the whole package name or just a single component.

Then, you want to remove the whole version. You need to first remove
the version number, making sure it doesn't eat a bit of package name
as well. Then, you have to go back to the beginning of the string,
and remove the operator.

Or you want to add a version. That one is simpler -- you just need to
go to one end of the dep, add the operator, then to the other, and add
the version.


The fore-mentioned problems could be solved through introducing a more
natural dependency syntax:

  PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]


This way:

1. It follows exactly how people are reading it:

  PACKAGE-NAME [is VERSION-OP than PACKAGE-VERSION]

2. It is always clear what is the version, and what is not.
Additionally, it allows you to introduce whitespace to increase
readability even more:

  dev-foo/bar-very-long-my-name-is-4-beta >= 17

3. The optional (version dependency) part is at one side
of the string, so it is easy to add, change or remove. Two times ^w
and done!

4. It follows the syntax used by bash (for conditionals), pkg-config
-- it is more natural in the environment.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Ulrich Mueller]

>>>>> On Sat, 22 Sep 2012, Michał Górny wrote:

> A package name can't end up with something looking like version.

> Thus, if upstream names package:

>   frobnicator-11

> We need to rename it in the tree, effectively losing the ability to
> follow upstream naming and introducing a bunch of unnecessary MY_P,
> S variables.

You need to be more precise here. Package names like "foo-1a" or
"foo-2_alpha" are perfectly legal, see the discussion in bug 174536.

What is currently not allowed are package names ending with a hyphen
followed by digits only (as in your above example). This seems to be
completely arbitrary, and we could remove this limitation, even with
existing dependency syntax.

Ulrich

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Sat, 22 Sep 2012 10:18:31 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sat, 22 Sep 2012, Michał Górny wrote:
> 
> > A package name can't end up with something looking like version.
> 
> > Thus, if upstream names package:
> 
> >   frobnicator-11
> 
> > We need to rename it in the tree, effectively losing the ability to
> > follow upstream naming and introducing a bunch of unnecessary MY_P,
> > S variables.
> 
> You need to be more precise here. Package names like "foo-1a" or
> "foo-2_alpha" are perfectly legal, see the discussion in bug 174536.
> 
> What is currently not allowed are package names ending with a hyphen
> followed by digits only (as in your above example). This seems to be
> completely arbitrary, and we could remove this limitation, even with
> existing dependency syntax.

I doubt we can. And we just extended it into repository names, didn't
we?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Ulrich Mueller]

>>>>> On Sat, 22 Sep 2012, Michał Górny wrote:

>> What is currently not allowed are package names ending with a hyphen
>> followed by digits only (as in your above example). This seems to be
>> completely arbitrary, and we could remove this limitation, even with
>> existing dependency syntax.

> I doubt we can.

Nobody could tell me a technical reason why this limitation exists.
Why should "foo-1" be forbidden for PN if "foo-1a" is allowed?

> And we just extended it into repository names, didn't we?

Indeed, looks like I've missed this. But it shouldn't be a problem, if
we loosen the spec for package names, the one for repository names
just follows it.

Ulrich

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Sep 22, 2012 10:58 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
> Hello,
>
> The current dependency syntax:
>
>   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:

The syntax you are describing is used all over portage, not just
dependencies. Some examples are the /etc/portage/package.* files,
has_version or exact version matching when emerging.

Changing it just for dependencies would most certainly confuse people and
tbh I like the current syntax :-)

Alex | wired

[-- Attachment #2: Type: text/html, Size: 706 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Sat, 22 Sep 2012 12:07:38 +0300
Alex Alexander <wired@gentoo.org> wrote:

> On Sep 22, 2012 10:58 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
> >
> > Hello,
> >
> > The current dependency syntax:
> >
> >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
> 
> The syntax you are describing is used all over portage, not just
> dependencies. Some examples are the /etc/portage/package.* files,
> has_version or exact version matching when emerging.

Yes, having it in all cases would be good.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Luca Barbato]

On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
> 
> The current dependency syntax:
> 
>   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> 
> suffers a few problems:

I like the current syntax.

lu

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

On Sat, 22 Sep 2012 17:12:04 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 09/22/2012 09:55 AM, Michał Górny wrote:
> > Hello,
> > 
> > The current dependency syntax:
> > 
> >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> > 
> > suffers a few problems:
> 
> I like the current syntax.

Does that invalidate my arguments?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Sat, 22 Sep 2012 09:55:08 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> The fore-mentioned problems could be solved through introducing a more
> natural dependency syntax:
> 
>   PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]

If we'd rather not break backwards compatibility and add in all kinds
of whitespace-related mess, another option is cat/pkg[>=2.3].

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Luca Barbato]

On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
> 
> The current dependency syntax:
> 
>   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> 
> suffers a few problems:

I like the current one your proposal seems quite a problem for a large
deal of usecases.

> 1. It is not really human-friendly.
> 
> People don't say things like:
> 
>   I need newer than monkey-1.2.
> 
> They say instead:
> 
>   I need monkey, newer than version 1.2.

"I need monkey-1.2 or newer" sounds natural to me.

> 2. With long package names and versions, it becomes hard-to-read.
> 
> Consider the following:
> 
>   >=dev-foo/bar-very-long-my-name-is-4-beta-17
> 
> Where does the version number start? And yes, this is a valid package
> name to our rules.


> 4. Adding, removing and changing versions is not friendly at all.
> 
> Consider the following dep:
> 
>   >=dev-foo/bar-bas-bat-11.2.4_alpha
> 
> Now, you want to bump the dep to 11.3. You need to find the version
> number, and modify it. Depending on the configuration, ^w is going to
> eat the whole package name or just a single component.

Use a better editor.

> Then, you want to remove the whole version. You need to first remove
> the version number, making sure it doesn't eat a bit of package name
> as well. Then, you have to go back to the beginning of the string,
> and remove the operator.

>   PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]

whitespace as separator for atoms looks a huge can of worms waiting to
be opened. how you'd pass that to emerge? How you make a list of atoms?

Please try not fix/break what is not broken.

lu

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On Sat, 22 Sep 2012 18:13:48 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 09/22/2012 09:55 AM, Michał Górny wrote:
> > Hello,
> > 
> > The current dependency syntax:
> > 
> >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> > 
> > suffers a few problems:
> 
> I like the current one your proposal seems quite a problem for a large
> deal of usecases.
> 
> > 1. It is not really human-friendly.
> > 
> > People don't say things like:
> > 
> >   I need newer than monkey-1.2.
> > 
> > They say instead:
> > 
> >   I need monkey, newer than version 1.2.
> 
> "I need monkey-1.2 or newer" sounds natural to me.

'monkey-1.2' or 'monkey version 1.2'? The former being a package name.

> > 4. Adding, removing and changing versions is not friendly at all.
> > 
> > Consider the following dep:
> > 
> >   >=dev-foo/bar-bas-bat-11.2.4_alpha
> > 
> > Now, you want to bump the dep to 11.3. You need to find the version
> > number, and modify it. Depending on the configuration, ^w is going
> > to eat the whole package name or just a single component.
> 
> Use a better editor.

Which one has automagic atom stripping?

> > Then, you want to remove the whole version. You need to first remove
> > the version number, making sure it doesn't eat a bit of package name
> > as well. Then, you have to go back to the beginning of the string,
> > and remove the operator.
> 
> >   PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]
> 
> whitespace as separator for atoms looks a huge can of worms waiting to
> be opened. how you'd pass that to emerge? How you make a list of
> atoms?

emerge 'foo >= 1.1' 'bar < 1.0'?
emerge foo '>=' 1.1 bar '<' 1.0?

And what do you mean by 'a list of atoms'? I don't see a single problem
parsing this syntax. It's a very simple stream of tokens.

> Please try not fix/break what is not broken.

So we're now switching Gentoo to EOL and just fixing bugs?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
> emerge 'foo >= 1.1' 'bar < 1.0'?
> emerge foo '>=' 1.1 bar '<' 1.0?

How is the above easier to read than

emerge >=foo-1.1 <bar-1.0

?

I think your example is working against you*.*

The current syntax is much easier to read than the
quote-and-whitespace-tracking horror of your example :-P

Alex | wired

[-- Attachment #2: Type: text/html, Size: 636 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Sat, 22 Sep 2012 20:11:48 +0300
Alex Alexander <wired@gentoo.org> wrote:

> On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
> >
> > emerge 'foo >= 1.1' 'bar < 1.0'?
> > emerge foo '>=' 1.1 bar '<' 1.0?
> 
> How is the above easier to read than
> 
> emerge >=foo-1.1 <bar-1.0

Did you even test it? That would create '=foo-1.1' and then fail trying
to read 'bar-1.0'. It's rather:

  emerge '>=foo-1.1' '<bar-1.0'

> I think your example is working against you*.*
> 
> The current syntax is much easier to read than the
> quote-and-whitespace-tracking horror of your example :-P

It's no less quoting than in the current case. And it could be simply
extended to supporting quoting-less syntax, e.g.:

  emerge foo -gt 1.1 bar -lt 1.0

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On Sep 22, 2012 8:25 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
> On Sat, 22 Sep 2012 20:11:48 +0300
> Alex Alexander <wired@gentoo.org> wrote:
>
> > On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
> > >
> > > emerge 'foo >= 1.1' 'bar < 1.0'?
> > > emerge foo '>=' 1.1 bar '<' 1.0?
> >
> > How is the above easier to read than
> >
> > emerge >=foo-1.1 <bar-1.0
>
> Did you even test it? That would create '=foo-1.1' and then fail trying
> to read 'bar-1.0'. It's rather:
>
>   emerge '>=foo-1.1' '<bar-1.0'

Yes, you are right, still much easier to read than your example tho.

Testing things is limited to very important stuff atm, I only have an
android phone and intermittent 3g available and ssh without a real kb is a
pain :-)

> > I think your example is working against you*.*
> >
> > The current syntax is much easier to read than the
> > quote-and-whitespace-tracking horror of your example :-P
>
> It's no less quoting than in the current case. And it could be simply
> extended to supporting quoting-less syntax, e.g.:
>
>   emerge foo -gt 1.1 bar -lt 1.0

I still find whitespace inappropriate for this kind of things. You are
trying to replace a single atom that instantly gives you all required
information with a format that does not clearly separate atoms, IMHO anyway
:-)

Alex | wired

[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Luca Barbato]

Alex Alexander <wired@gentoo.org> wrote:

>On Sep 22, 2012 8:25 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
>>
>> On Sat, 22 Sep 2012 20:11:48 +0300
>> Alex Alexander <wired@gentoo.org> wrote:
>>
>> > On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
>> > >
>> > > emerge 'foo >= 1.1' 'bar < 1.0'?
>> > > emerge foo '>=' 1.1 bar '<' 1.0?
>> >
>> > How is the above easier to read than
>> >
>> > emerge >=foo-1.1 <bar-1.0
>>
>> Did you even test it? That would create '=foo-1.1' and then fail
>trying
>> to read 'bar-1.0'. It's rather:
>>
>>   emerge '>=foo-1.1' '<bar-1.0'
>
>Yes, you are right, still much easier to read than your example tho.
>
>Testing things is limited to very important stuff atm, I only have an
>android phone and intermittent 3g available and ssh without a real kb
>is a
>pain :-)
>
>> > I think your example is working against you*.*
>> >
>> > The current syntax is much easier to read than the
>> > quote-and-whitespace-tracking horror of your example :-P
>>
>> It's no less quoting than in the current case. And it could be simply
>> extended to supporting quoting-less syntax, e.g.:
>>
>>   emerge foo -gt 1.1 bar -lt 1.0
>
>I still find whitespace inappropriate for this kind of things. You are
>trying to replace a single atom that instantly gives you all required
>information with a format that does not clearly separate atoms, IMHO
>anyway

+1

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Luca Barbato]

No.

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Ben de Groot]

On 23 September 2012 00:13, Luca Barbato <lu_zero@gentoo.org> wrote:
> Please try not fix/break what is not broken.

+1

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Diego Elio Pettenò]

On 22/09/2012 09:35, Ben de Groot wrote:
>> > Please try not fix/break what is not broken.
> +1

Same here.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote:
> Hello,
> 
> The current dependency syntax:
> 
>   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> 
> suffers a few problems:
> 
> 
> 1. It is not really human-friendly.
> 
> People don't say things like:
> 
>   I need newer than monkey-1.2.
> 
> They say instead:
> 
>   I need monkey, newer than version 1.2.
> 
[snip :/ ]

> 4. It follows the syntax used by bash (for conditionals), pkg-config
> -- it is more natural in the environment.
> 

The BIG problem with that is bash has nothing to do with evaluating
dependencies.  All bash does is source the *DEPEND and pass the value to
the package manager which does all the processing.  And all 3 current
package managers are set up to parse those dep strings with a set syntax
and whitespace. None of the PM's dependency resolvers are written in
bash, two are python based, one C++. This proposal would throw a big
monkey wrench into parsing those strings.  Introducing lots of bugs,
both in the PM and the ebuilds.

And this after all the fuss about the unified DEPENDENCIES proposal,
which is a small syntax change for the current processing code, easily
incorporated into the PM's. AND has definite, measurable advantages. 

so, -1
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On Sat, 22 Sep 2012 10:05:41 -0700
Brian Dolbec <dolsen@gentoo.org> wrote:

> On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote:
> > Hello,
> > 
> > The current dependency syntax:
> > 
> >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> > 
> > suffers a few problems:
> > 
> > 
> > 1. It is not really human-friendly.
> > 
> > People don't say things like:
> > 
> >   I need newer than monkey-1.2.
> > 
> > They say instead:
> > 
> >   I need monkey, newer than version 1.2.
> > 
> [snip :/ ]
> 
> > 4. It follows the syntax used by bash (for conditionals), pkg-config
> > -- it is more natural in the environment.
> > 
> 
> The BIG problem with that is bash has nothing to do with evaluating
> dependencies.  All bash does is source the *DEPEND and pass the value
> to the package manager which does all the processing.  And all 3
> current package managers are set up to parse those dep strings with a
> set syntax and whitespace. None of the PM's dependency resolvers are
> written in bash, two are python based, one C++. This proposal would
> throw a big monkey wrench into parsing those strings.  Introducing
> lots of bugs, both in the PM and the ebuilds.

It has all to do with people writing ebuilds.

Also, I don't really see a problem with parsing it. Bash is not really
relevant here; Python and C++ doesn't have a problem with either
syntax. It's just about correct tokenizer design.

> And this after all the fuss about the unified DEPENDENCIES proposal,
> which is a small syntax change for the current processing code, easily
> incorporated into the PM's.

Err, no, it isn't. It requires redesigning ebuilds, cache, and probably
a lot of code paths in the dependency parser unless the new syntax is
going to be converted back to old one.

Mine is easily incorporated into the PM; it is just a change
in a single place splitting and parsing the tokens.

> AND has definite, measurable advantages. 

We still didn't get a single one.

So, I think you just don't like it and are inventing disadvantages
without even caring enough to consider them before writing.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

oops, didn't reply to the list.  re-sending

On Sat, 2012-09-22 at 19:19 +0200, Michał Górny wrote:
> On Sat, 22 Sep 2012 10:05:41 -0700

> So, I think you just don't like it and are inventing disadvantages
> without even caring enough to consider them before writing.
> 

Oh, I considered it for the past 4 hours before responding.  Got nothing
in favour of it.

The current atom format and syntax in CONSISTENT throughout the configs,
and PM code.  This proposal would split that in two, configs, ebuilds
one format, everything else the old. 

quote "
Mine is easily incorporated into the PM; it is just a change
in a single place splitting and parsing the tokens.
"
 That is unless you also change all the code to the new format and a new
data type.

I have written *DEPEND processing code (porthole's grahical Dependencies
view) and worked on code in portage, pkgcore, gentoolkit, gpytage,...
all working with the current atom syntax.  This proposed change would
require all those tools and more to be refactored too!

So, to throw your words back at you:

This proposal was submitted ... "without even caring enough to consider
them before writing."


enough said.
-- 
Brian Dolbec <dolsen@gentoo.org>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[Brian Harring]

On Sat, Sep 22, 2012 at 07:19:09PM +0200, Micha?? G??rny wrote:
> On Sat, 22 Sep 2012 10:05:41 -0700
> Brian Dolbec <dolsen@gentoo.org> wrote:
> 
> > On Sat, 2012-09-22 at 09:55 +0200, Micha?? G??rny wrote:
> > > Hello,
> > > 
> > > The current dependency syntax:
> > > 
> > >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> > > 
> > > suffers a few problems:
> > > 
> > > 
> > > 1. It is not really human-friendly.
> > > 
> > > People don't say things like:
> > > 
> > >   I need newer than monkey-1.2.
> > > 
> > > They say instead:
> > > 
> > >   I need monkey, newer than version 1.2.
> > > 
> > [snip :/ ]
> > 
> > > 4. It follows the syntax used by bash (for conditionals), pkg-config
> > > -- it is more natural in the environment.
> > > 
> > 
> > The BIG problem with that is bash has nothing to do with evaluating
> > dependencies.  All bash does is source the *DEPEND and pass the value
> > to the package manager which does all the processing.  And all 3
> > current package managers are set up to parse those dep strings with a
> > set syntax and whitespace. None of the PM's dependency resolvers are
> > written in bash, two are python based, one C++. This proposal would
> > throw a big monkey wrench into parsing those strings.  Introducing
> > lots of bugs, both in the PM and the ebuilds.
> 
> It has all to do with people writing ebuilds.
> 
> Also, I don't really see a problem with parsing it. Bash is not really
> relevant here; Python and C++ doesn't have a problem with either
> syntax. It's just about correct tokenizer design.
> 
> > And this after all the fuss about the unified DEPENDENCIES proposal,
> > which is a small syntax change for the current processing code, easily
> > incorporated into the PM's.
> 
> Err, no, it isn't. It requires redesigning ebuilds, cache, and probably
> a lot of code paths in the dependency parser unless the new syntax is
> going to be converted back to old one.

It requires none of those things you claim.

I know this since I actually wrote patches for it already.

You should know this since you responded to that exact email, and 
have been very active in that thread.  I laid out exactly how this 
plugged into our existing design and posted patches proving it.

Phrased as nicely as I can, you're trolling, poorly at that.  Please 
desist.

Reiterating it again for others who weren't as active in that thread, 
patches are here:
http://dev.gentoo.org/~ferringb/unified-dependencies/patches/


> Mine is easily incorporated into the PM; it is just a change
> in a single place splitting and parsing the tokens.

You really need to do a walk through portage internals.

All ebuild based parsers are whitespace based parsing; the sole 
exception is for src_uri's -> file rename, and by large that code is a 
bit icky for each; in portages case, doubly so frankly 
(pkgcore/paludis use a reversible iterator design in that case; less 
icky, but it throws off the normal flow ).

This isn't a simple change for the PM; worse, it'll require two parse 
tree codebases since trying to inline your notion in would fuck the 
code up something fierce in terms of maintenence/flow.

If you'd like to argue that, I'd suggest you take pkgcore and modify 
it for your intent (the parse code is pkgcore/ebuild/conditionals.py; 
it's the simplest but full implementation out there imo, thus the 
suggestion), while preserving parsing support for the old format; 
just the python side, you don't need to do the c extension.

Post that patch and prove it; else... bluntly, you're arguing w/ 
authors about their own code.  That usually isn't a scenario people 
win.  Some authors may be retards, hell, I may be, but I'm not wrong 
on that section of code across the managers.


> > AND has definite, measurable advantages. 
> 
> We still didn't get a single one.
> 
> So, I think you just don't like it and are inventing disadvantages
> without even caring enough to consider them before writing.


Just kicking the corpse to make damn sure it stays down, here's the 
flaws I saw pretty much immediately in reading the first email; if an 
hour was spent, I'm sure worse issues could be found. 

*) cocks up emerge invocation.  Previously `emerge 
=dev-util/diffball-1`; your proposal, `emerge 'dev-util/diffball = 
1'`.  You argue "well you already have to quote for > or <"; thing is, 
we don't have to quote for equals, and you now require it- globbed 
versions, same thing.

*) If you argue "emerge should just collapse the args if given 
`emerge dev-util/diffball = 1`, then I suggest *you* write that code, 
and maintain it.  It'd take a strong council action before I did that 
in pkgcore.  I think it's that level of wrong.

*) The proposal completely overlooked profiles.  We'd have to 
use the old form through out the entirety of the profiles.  Woot, 
maintaining two dep syntax/parse trees indefinitely...

* *) This requires changing the parsing rules of every single atom 
based file in the profile tree.  Anything use related 
(package.use.mask) is whitespace split; not anymore it ain't.  Code 
duplication baby, lots of it.

*) The proposal ignores metadata/updates; more importantly, updates 
are unversioned- we have no EAPI awareness in there.  Meaning updates 
would have to be the old form indefinitely.

*) The proposal completely ignored slot deps, repository deps, use 
deps.  You're arguing thus:

sys-apps/portage[build] >= 2.1
sys-apps/portage:0[build] =~ 2.2
sys-apps/portage::gentoo <= 2.2

*) This force duplication of atom parsing implementations; currently, 
they all basically extract a cpv out of it if '<>=~' are seen; if 
those operators aren't there, they split on '/'.  Either the PM would 
have to maintain duplicate parsing pathways/validation, or it would 
(most likely) collapse your form down into the old form since we 
already have well tested code that handles that.

*) This doesn't address profiles/news at all.  I expect complications 
to ensue there too, especially considering... wait for it... the atoms 
in use there aren't EAPI versioned.  Meaning old form is required 
indefinitely.


Again, I suggest you read up on the guts of existing package managers; 
read he source.  Additionally, please at least do a basic validation 
of the notion before just throwing it at the dev ml; it may not matter 
to you, but that's 21 more emails people have to read due to the basic 
legwork not being done.

~harring

Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
> 
> The current dependency syntax:
> 
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> 
> suffers a few problems:
> 
> 
> 1. It is not really human-friendly.
> 
> People don't say things like:
> 
> I need newer than monkey-1.2.
> 
> They say instead:
> 
> I need monkey, newer than version 1.2.
> 
> 
> 2. With long package names and versions, it becomes hard-to-read.
> 
> Consider the following:
> 
>> =dev-foo/bar-very-long-my-name-is-4-beta-17
> 
> Where does the version number start? And yes, this is a valid
> package name to our rules.
> 
> 
> 3. Some potentially colliding package names are disallowed.
> 
> A package name can't end up with something looking like version.
> Thus, if upstream names package:
> 
> frobnicator-11
> 
> We need to rename it in the tree, effectively losing the ability
> to follow upstream naming and introducing a bunch of unnecessary
> MY_P, S variables.
> 
> 
> 4. Adding, removing and changing versions is not friendly at all.
> 
> Consider the following dep:
> 
>> =dev-foo/bar-bas-bat-11.2.4_alpha
> 
> Now, you want to bump the dep to 11.3. You need to find the
> version number, and modify it. Depending on the configuration, ^w
> is going to eat the whole package name or just a single component.
> 
> Then, you want to remove the whole version. You need to first
> remove the version number, making sure it doesn't eat a bit of
> package name as well. Then, you have to go back to the beginning of
> the string, and remove the operator.
> 
> Or you want to add a version. That one is simpler -- you just need
> to go to one end of the dep, add the operator, then to the other,
> and add the version.
> 
> 
> The fore-mentioned problems could be solved through introducing a
> more natural dependency syntax:
> 
> PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]
> 
> 
> This way:
> 
> 1. It follows exactly how people are reading it:
> 
> PACKAGE-NAME [is VERSION-OP than PACKAGE-VERSION]
> 
> 2. It is always clear what is the version, and what is not. 
> Additionally, it allows you to introduce whitespace to increase 
> readability even more:
> 
> dev-foo/bar-very-long-my-name-is-4-beta >= 17
> 
> 3. The optional (version dependency) part is at one side of the
> string, so it is easy to add, change or remove. Two times ^w and
> done!
> 
> 4. It follows the syntax used by bash (for conditionals),
> pkg-config -- it is more natural in the environment.
> 

KISS is not just about simplicity of a system, but also about
simplicity of changes and how big the gain is when the changes are not
simple.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXhRmAAoJEFpvPKfnPDWzFJoH/jzjfVtHzbv3VUPJYl4WZSkq
ztNaFp8SPSeMS10sM48Pt2l3JkHnOlN8hiXS4zq9Gy9VLKT3rkP94h8g3Gmh8biP
pcHxGEpZOFV5ATuI2MNBDrF7LI8S0eVoOkutEQPAUwmI8NRzrj0DpEwYlmsUDxwE
aD5vtMWLl02X6dnZfdLUN/zBo/T3jNWuLUyPmKWwB7qkIH+2W0y3ZxdBJmdA4VYl
ImrIM7RAhUgBb3cPtmloPt7rfYH/AGoS1O2M6eEZo1N2TmeZ4YwwciOmYfZrHWkc
AZzGs9yt0ElMkZrNNdHZlblyQhdZJ8xO2WhJrvmeG+HtwUJgtxDtYbowkkunLoM=
=5PkR
-----END PGP SIGNATURE-----