Re: [gentoo-dev] [Proposal] Eclass for nodejs modules

[Geaaru <geaaru@gmail.com>]

Hi Andrew,

thanks for reply. My comment hereinafter.


On Mon, 2016-02-29 at 02:12 -0800, Andrew Udvare wrote:
> > On 2016-02-29, at 01:38, Geaaru <geaaru@gmail.com> wrote:
> > 
> > Hi guys,
> > 
> > I create an eclass that permit to create ebuild for nodejs modules
> > without define every times ebuild phases and avoid install of
> > dependencies already present on system.
> > My mission is create a module like perl-gpan that permit of create
> > automatically all ebuilds of every dependencies (not
> > devDependencies)
> > of a particular package and npmv1 eclass if first step for this.
> 
> http://search.gmane.org/?query=nodejs&group=gmane.linux.gentoo.devel
> 
> Unfortunately the conversation has already happened and it has sort
> of been determined that the community (even worse than Go) is
> terrible at defining dependencies for a lot of projects, even major
> ones. Personally for ebuilds I'm only interested in the end user
> packages that often documentation says to install using `npm install
> -g` (which I never do); packages that are useful for command line
> generally. I have resorted to using nvm for a few reasons: ease of
> use, compatibility, testing, and the fact that nodejs is not slotted
> in the Portage tree. Even if Gentoo had slots for nodejs/npm, it
> would not make it easier to test against different versions the way
> nvm does. In particular with time some versions would go away before
> other distros upgrade.
> 
> Your eclass kind of does something, as far as i can tell, which is
> very discouraged. Line 84 shows it downloading the dependencies with
> npm install to create sort of a separate root of the package, and
> then you generate a script to launch with the correct environment
> variables (and yes you avoid getting stuff already on the system).
> It's like nvm but done with Portage, but for each package. Users are
> not in control of the ebuild if they cannot specify how things get
> downloaded (make.conf can customise the command). NPM_DEFAULT_OPTS
> does not document how one could add proxy options. Even if you undid
> the npm install by invoking the user's command to download the
> packages, it would still not be acceptable as packages must be able
> to live in distfiles. I also do not see what you are going to do when
> package1 is already installed depending on dep1 version 1.2 but now
> package2 wants to be installed wanting dep1 on version 2.2. Automagic
> slotting?

The idea is that as first step I create manually dependencies of every
package/ ebuild and where is available a system package I use
NPM_SYSTEM_MODULES to exclude module from install. I know, it isn't a
fine solution but as I wrote I want create a module that try to create
ebuild automatically from package.json and when I do that I can avoid
to use npm install on src_prepare phase.
For now on src_prepare I use npm install to download dependencies with
exact version match (I add -E option on NPM_DEFAULT_OPTS for do this).
About your question for dependencies conflits (and slotting) is equal
to a normal package. See you packages about Openstack project where
Juno release has a lot of dependencies restrictions like package1
>=1.2, package <= 2.2.
Yes, I know that is not easy to maintain ebuilds upgraded but like
happens now in a lot of gentoo ebuilds, if a project is not more
maintained (and so it isn't usable with more updated dependencies) is
removed from portage.


> 
> > 
> > ...like for perl I think that manage nodejs modules as gentoo
> > package is more clear than use directly npm features.
> 
> I kind of disagree. The current state of nodejs packaging just does
> not allow for easy external packaging except for basically what you
> are doing which is using npm install, or vendoring every package to
> avoid conflicts.
> 
> You must get the individual packages and set up separate ebuilds and
> they must be able to share dependencies in most cases. The problem is
> the contents of package.json is often to just get 'the latest'
> version of every dependency or extremely incompatible versions. The
> community is moving too quickly for Portage to always be up-to-date
> with this.

I do not agree with this, I think that manage nodejs module inside
Portage is possible, not easy, but possible and more easy to manage
instead of npm command.
There is same problem with perl modules, CPAN normally has more updated
modules but currently ebuild about perl modules are present.
About your comment for 'the latest', normally FWIS dependencies are
with version with (~) that it's means get the latest or same version,
but with -E option to npm command you can force use of same versions.

> 
> The same problem exists with Java packages that use Maven for
> dependency management. It is almost as bad as Go, but the importance
> of some Go packages (Docker) is outweighing the complexity of
> reverse-engineering the `go get` mentality of that community. They
> basically do not want users to not use `go get` if it's available.
> They really want users to stick to their language-specific package
> managers. As a result of the Go unpredictability with versions, there
> are plenty of projects that 'vendor' their dependencies including
> Docker.
> 
> https://gist.github.com/datagrok/8577287
> 
> In particular, Python and Ruby seem to have settled versioning a lot
> more. Most packages do not specify Git repositories @ HEAD or any
> strange things like that. Releases get made in a predictable manner
> for the popular packages, because the consumers demand stability and
> predictability. (Ruby is not non-guilty, take a look at Vagrant.)
> 
> Also line 236:
> 
> npm_pkg_mods=( $(ls --color=none node_modules/) )
> 
> This should be npm_pkg_mods=( node_modules/* ) (and then call
> basename on each when iterating).

Thank you for your suggestion, but with npm_pkg_mods=( node_modules/* )
if there aren't directories under node_modules on variable is then
present an entry with node_modules/*, instead if I use ls an empty row
is returned.

> 
> Andrew
> 
> 

In conclusion, it seems that is not accepted use of nodejs modules
ebuild inside portage. It is right?