On 12 March 2012 15:20, Rich Freeman <ri...@gentoo.org> wrote: > On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring <ferri...@gmail.com> wrote: >> Pragmatic reality, the eapi function actually would work fine. As >> pointed out elsewhere, bash parses as it goes- which isn't going to >> change. > > Unless the ebuild isn't written in bash... > > How do you source the ebuild if you don't know what to use to source > it? How do you know what to use to source it if you don't know the > EAPI? Right now all the existing EAPIs use bash, but there is no > reason the file couldn't be xml, or python, or just about anything > else.
A convention that is often used in this scenario is to combine a hashbang call with that specific sourcer stripping that hashbang prior to the parse. ie: foo.ebuild: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process "eapi-xml-5" ( as defined by the current $PATH setting ) This process can easily then strip the #! stanza before sending the content to an XML parser. ( ps. while I wouldn't actually use XML, its a good example case because standard shell-script style commenting is illegal syntax in XML ) The benefits of this approach seem obvious, but there are also obvious downsides. 1. PRO: Unlike /usr/bin/eapi , this style is PMS Agnostic, and only requires the PMS have a process named "eapi-xml-5" *somewhere* in the system under $PATH 2. CON: Unlike /usr/bin/eapi , you're limited by what you can send it , /usr/bin/env eapi xml-5 would be preferable syntax imo, but it doesn't work, because its parsed as [ '/usr/bin/env' , 'eapi xml-5' ] which then yeilds a "permission denied" due to no command with that name existing. 3. PRO: There's not /much/ risk of a user trying to run it directly, mostly because there's no +x bit 4. CON: This syntax is going to conflict with whatever language we are proceeding, which while this caveat is dealt with by the command that the file is dispatched to, its a lot of work getting everything else to play ball ( editors won't understand, linters wont understand, various other tools that work strictly with the native forms of that language wont understand ) and this problem exists for *every* case where the coding system we're targeting doesn't natively support whatever "magic" indicators we're trying to stuff in the file. 5. PRO: detecting this notation being used in a file is cheap-ish , you only have to read 2 characters into the file to know its using this notation. As a result of all these, it seems to me if we ever want to support non-bash or non-scripting sources ( ie: YAML, JSON, XML , etc ) or any other language which doesn't support "# is a comment" , we're going to be pretty much forced to declare the EAPI outside the file somehow. Whether this is via the filename ( yes, I've seen that debate ) or via some other metadata file ( which seems more poison than cure ) would be the real issue. Having to store this in a metadata file that maps *.ebuild to EAPI would seem like a solution that would only increase the filesize of portage, and slow down runtime substantially, unless of course you had a per-repository index that sped this up and was generated during the metadata/ generation phase. Then $PMS could just load that file from each repository , and assuming the cache was still valid, it could easily know the EAPI for any .ebuild it would source in advance. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
