From Fedora Project Wiki

(Doubt about naming conventions.)
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 9: Line 9:
== Naming conventions ==
== Naming conventions ==


I am not sure about the ''nodejs-'' prefix. At the end, the package contains just JavaScript files, which might be executed by whatever JS engine available on the system, which is by coincidence Node.js ATM, but it could be other interpreter in the future. For example, there exist rubygem-execjs library, which can execute JavaScript files using vairous JavaScript engines, starting by Node, SpiderMonkey, V8 and ending by Microsoft Windows Script Host (although this one is not relevant on linux ;) Yes, I understand that there might be some shebang, that pints to node, but we are now solving similar issues in Ruby world, due to JRuby [[User:vondruch|Vít Ondruch]] 2013-01-17 12:26 UTC
I am not sure about the ''nodejs-'' prefix. At the end, the package contains just JavaScript files, which might be executed by whatever JS engine available on the system, which is by coincidence Node.js ATM, but it could be other interpreter in the future. For example, there exist rubygem-execjs library, which can execute JavaScript files using vairous JavaScript engines, starting by Node, SpiderMonkey, V8 and ending by Microsoft Windows Script Host (although this one is not relevant on linux ;) Yes, I understand that there might be some shebang, that points to node, but we are now solving similar issues in Ruby world, due to JRuby - [[User:vondruch|Vít Ondruch]] 2013-01-17 12:26 UTC
 
:Do these implementations implement the node standard library (e.g. <code>require()</code>)?  Do they read package.json to identify the entry point for the module?  Do they offer any compatibility with the Node.js native module ABI?  Most of the packages I've done so far have explicit dependencies on the node engine in their package.json. 
 
:We're going to need complete JavaScript guidelines that take into account server and client-side JavaScript in the future, and it'll probably involve things like one SRPM providing client and server-side packages.  But I think that's out of scope for the moment.  I'm currently more worried about stuff that is almost certainly node specific, like npm, and that's what these guidelines are intended to cover.  I definitely want to iterate upon them for F20 and beyond.  --[[User:Patches|Patches]] ([[User talk:Patches|talk]]) 02:02, 18 January 2013 (UTC)
 
== sitelib and sitearch ==
 
Is there notion about vendorlib and vendor arch as well? There are all four directories available in Ruby and there is small distinction in their meaning. The vendorlib is used for stuff distributed by vendor while sitelib is for libraries installed by local admin, therefore in Ruby, the vendorlib points to /usr/shared where sitelib points to /usr/local. - [[User:vondruch|Vít Ondruch]] 2013-01-17 12:47 UTC
 
:Nope.  The only search path node uses is ./node_modules.  /usr/lib/node_modules is an npm convention, and installing RPMs there allows users to use `npm link` to bring them into their personal projects.  For more information on how module loading in node works, see [http://lists.fedoraproject.org/pipermail/devel/2013-January/176082.html this message on fedora-devel]  --[[User:Patches|Patches]] ([[User talk:Patches|talk]]) 02:02, 18 January 2013 (UTC)
 
Second question for the same topic, which is sitelib poiting into /usr/lib? Shouldn't the files go into /usr/share, since they are platform independent?  - [[User:vondruch|Vít Ondruch]] 2013-01-17 12:47 UTC
 
:Again, this is following npm upstream.  I'd like to avoid breaking with upstream, especially since other interpreted languages use /usr/lib for the same purpose.  If people want to change it, they should work there.  --[[User:Patches|Patches]] ([[User talk:Patches|talk]]) 02:02, 18 January 2013 (UTC)

Latest revision as of 02:02, 18 January 2013

%nodejs_symlink_deps

"This macro should be called in the %install section of every Node.js module package."

Shouldn't that be "This macro should be called in the %install section of every Node.js module package that depends on other modules."? Churchyard (talk) 02:10, 17 January 2013 (UTC)

  • Actually, I'd rather it be called even for modules without deps, since it'll just do nothing. That way there won't be problems if the module adds deps later. I just added some language to this effect. --Patches (talk) 06:34, 17 January 2013 (UTC)

Naming conventions

I am not sure about the nodejs- prefix. At the end, the package contains just JavaScript files, which might be executed by whatever JS engine available on the system, which is by coincidence Node.js ATM, but it could be other interpreter in the future. For example, there exist rubygem-execjs library, which can execute JavaScript files using vairous JavaScript engines, starting by Node, SpiderMonkey, V8 and ending by Microsoft Windows Script Host (although this one is not relevant on linux ;) Yes, I understand that there might be some shebang, that points to node, but we are now solving similar issues in Ruby world, due to JRuby - Vít Ondruch 2013-01-17 12:26 UTC

Do these implementations implement the node standard library (e.g. require())? Do they read package.json to identify the entry point for the module? Do they offer any compatibility with the Node.js native module ABI? Most of the packages I've done so far have explicit dependencies on the node engine in their package.json.
We're going to need complete JavaScript guidelines that take into account server and client-side JavaScript in the future, and it'll probably involve things like one SRPM providing client and server-side packages. But I think that's out of scope for the moment. I'm currently more worried about stuff that is almost certainly node specific, like npm, and that's what these guidelines are intended to cover. I definitely want to iterate upon them for F20 and beyond. --Patches (talk) 02:02, 18 January 2013 (UTC)

sitelib and sitearch

Is there notion about vendorlib and vendor arch as well? There are all four directories available in Ruby and there is small distinction in their meaning. The vendorlib is used for stuff distributed by vendor while sitelib is for libraries installed by local admin, therefore in Ruby, the vendorlib points to /usr/shared where sitelib points to /usr/local. - Vít Ondruch 2013-01-17 12:47 UTC

Nope. The only search path node uses is ./node_modules. /usr/lib/node_modules is an npm convention, and installing RPMs there allows users to use npm link to bring them into their personal projects. For more information on how module loading in node works, see this message on fedora-devel --Patches (talk) 02:02, 18 January 2013 (UTC)

Second question for the same topic, which is sitelib poiting into /usr/lib? Shouldn't the files go into /usr/share, since they are platform independent? - Vít Ondruch 2013-01-17 12:47 UTC

Again, this is following npm upstream. I'd like to avoid breaking with upstream, especially since other interpreted languages use /usr/lib for the same purpose. If people want to change it, they should work there. --Patches (talk) 02:02, 18 January 2013 (UTC)