FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-22-2012, 07:51 PM
Luca Barbato
 
Default A more natural (human-friendly) syntax for dependencies

No.
 
Old 09-22-2012, 07:52 PM
Luca Barbato
 
Default A more natural (human-friendly) syntax for dependencies

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
 
Old 09-25-2012, 11:41 PM
Brian Harring
 
Default A more natural (human-friendly) syntax for dependencies

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
 

Thread Tools




All times are GMT. The time now is 03:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org