1 |
On 12 March 2012 15:20, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring <ferringb@×××××.com> wrote: |
3 |
>> Pragmatic reality, the eapi function actually would work fine. As |
4 |
>> pointed out elsewhere, bash parses as it goes- which isn't going to |
5 |
>> change. |
6 |
> |
7 |
> Unless the ebuild isn't written in bash... |
8 |
> |
9 |
> How do you source the ebuild if you don't know what to use to source |
10 |
> it? How do you know what to use to source it if you don't know the |
11 |
> EAPI? Right now all the existing EAPIs use bash, but there is no |
12 |
> reason the file couldn't be xml, or python, or just about anything |
13 |
> else. |
14 |
|
15 |
|
16 |
A convention that is often used in this scenario is to combine a |
17 |
hashbang call with that specific sourcer stripping that hashbang prior |
18 |
to the parse. |
19 |
|
20 |
ie: |
21 |
|
22 |
foo.ebuild: |
23 |
|
24 |
#!/usr/bin/env eapi-xml-5 |
25 |
|
26 |
would send the current file ( foo.ebuild ) to the process "eapi-xml-5" |
27 |
( as defined by the current $PATH setting ) |
28 |
|
29 |
This process can easily then strip the #! stanza before sending the |
30 |
content to an XML parser. |
31 |
|
32 |
( ps. while I wouldn't actually use XML, its a good example case |
33 |
because standard shell-script style commenting is illegal syntax in |
34 |
XML ) |
35 |
|
36 |
The benefits of this approach seem obvious, but there are also obvious |
37 |
downsides. |
38 |
|
39 |
1. PRO: Unlike /usr/bin/eapi , this style is PMS Agnostic, and only |
40 |
requires the PMS have a process named "eapi-xml-5" *somewhere* in the |
41 |
system under $PATH |
42 |
|
43 |
2. CON: Unlike /usr/bin/eapi , you're limited by what you can send it |
44 |
, /usr/bin/env eapi xml-5 would be preferable syntax imo, but it |
45 |
doesn't work, because its parsed as [ '/usr/bin/env' , 'eapi xml-5' ] |
46 |
which then yeilds a "permission denied" due to no command with that |
47 |
name existing. |
48 |
|
49 |
3. PRO: There's not /much/ risk of a user trying to run it directly, |
50 |
mostly because there's no +x bit |
51 |
|
52 |
4. CON: This syntax is going to conflict with whatever language we are |
53 |
proceeding, which while this caveat is dealt with by the command that |
54 |
the file is dispatched to, its a lot of work getting everything else |
55 |
to play ball ( editors won't understand, linters wont understand, |
56 |
various other tools that work strictly with the native forms of that |
57 |
language wont understand ) and this problem exists for *every* case |
58 |
where the coding system we're targeting doesn't natively support |
59 |
whatever "magic" indicators we're trying to stuff in the file. |
60 |
|
61 |
5. PRO: detecting this notation being used in a file is cheap-ish , |
62 |
you only have to read 2 characters into the file to know its using |
63 |
this notation. |
64 |
|
65 |
|
66 |
As a result of all these, it seems to me if we ever want to support |
67 |
non-bash or non-scripting sources ( ie: YAML, JSON, XML , etc ) or any |
68 |
other language which doesn't support "# is a comment" , we're going to |
69 |
be pretty much forced to declare the EAPI outside the file somehow. |
70 |
|
71 |
Whether this is via the filename ( yes, I've seen that debate ) or via |
72 |
some other metadata file ( which seems more poison than cure ) would |
73 |
be the real issue. |
74 |
|
75 |
Having to store this in a metadata file that maps *.ebuild to EAPI |
76 |
would seem like a solution that would only increase the filesize of |
77 |
portage, and slow down runtime substantially, unless of course you had |
78 |
a per-repository index that sped this up and was generated during the |
79 |
metadata/ generation phase. |
80 |
|
81 |
Then $PMS could just load that file from each repository , and |
82 |
assuming the cache was still valid, it could easily know the EAPI for |
83 |
any .ebuild it would source in advance. |
84 |
|
85 |
-- |
86 |
Kent |
87 |
|
88 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
89 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |