> On 2016-02-29, at 01:38, Geaaru <gea...@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? > > ...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. 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). Andrew
