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@g.o> 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