Donnie Berkholz wrote:
> On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote:
>> looks like every nominee wants the council to be more technical so I
>> have a few technical questions for you:
>> 1. GLEP54
>> 2. GLEP55
> I don't have any particular objections to these, besides the vague
> aesthetic one of having EAPI in the filename. Particularly long, weird
> EAPIs filled with special characters (to which some will reply "So don't
> do that").
Donnie, I agree, and I think it would be a mistake to use the filename
extension for the EAPI number, even for simple "non-long-or-funky"
EAPIs. I know that my reasons will be considered, by some, to be
irrelevant (especially since aesthetics and/or style/elegance are of less
importance to some), but I really think this should be carefully considered;
a mistake here would be quite a shame. I'll state again (slightly modified)
what I wrote a while back on this issue.
Technical reasons to avoid the filename:
1) Increase of [needless] complexity in filenames/extensions (and only one
example of the impact is that searching for ebuild files becomes less
straightforward), when things like SLOT, EAPI, etc., etc., seem to
naturally belong as part of the script contents/syntax.
2) Having the same info in more than one place is generally a bad idea in
any design - this is true in any discipline. I don't care how many people
say a) that this is not an issue or b) that it's "not a duplication",
in every data system I've worked on, it has been a very bad idea to have
more than one version of the same info that can get out of sync with each
other. Even if you take great care, I'd still always want to check both
and not trust either version of the info blindly. Caching or hashing is
different (i.e. where the caching mechanism is robust), since the
system itself keeps the cache up to date, and one version of the info
is strictly derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers,
especially *nix. No longer could we then say that a file of type
"Gentoo ebuild" has the extension "ebuild"
4) It seems that the motivation for this GLEP is so that the tools can
determine the EAPI without reading/sourcing the script. In order to
get around this, the GLEP suggests exposing this technical information
in the filename. This is the wrong place to expose it, and the reasons
given are not that this detail should be exposed there but rather because
it is inefficient to source the file to get the info. So this is a case
of trying to solve a technical issue by changing the interface. I
believe it would be more correct to attack the technical problem in a way
that does not do this, and I am sure this can be solved.
1) Littering the filename with this kind of stuff is potentially confusing to
both devs and users - I know it's been stated that users shouldn't care,
but I don't think that's a good reason/assumption.
2) It is not an elegant filename policy. Many systems have elegance as
a design goal.
3) Assuming going this route is a mistake, it could be hard to reverse.
Currently, I consider Gentoo's ebuild filename conventions simple and
elegant. In fact, it is beautifully done. I'd hate to see this go down the
wrong path now.
email@example.com mailing list