1 |
Hi Andrew, |
2 |
|
3 |
thanks for reply. My comment hereinafter. |
4 |
|
5 |
|
6 |
On Mon, 2016-02-29 at 02:12 -0800, Andrew Udvare wrote: |
7 |
> > On 2016-02-29, at 01:38, Geaaru <geaaru@×××××.com> wrote: |
8 |
> > |
9 |
> > Hi guys, |
10 |
> > |
11 |
> > I create an eclass that permit to create ebuild for nodejs modules |
12 |
> > without define every times ebuild phases and avoid install of |
13 |
> > dependencies already present on system. |
14 |
> > My mission is create a module like perl-gpan that permit of create |
15 |
> > automatically all ebuilds of every dependencies (not |
16 |
> > devDependencies) |
17 |
> > of a particular package and npmv1 eclass if first step for this. |
18 |
> |
19 |
> http://search.gmane.org/?query=nodejs&group=gmane.linux.gentoo.devel |
20 |
> |
21 |
> Unfortunately the conversation has already happened and it has sort |
22 |
> of been determined that the community (even worse than Go) is |
23 |
> terrible at defining dependencies for a lot of projects, even major |
24 |
> ones. Personally for ebuilds I'm only interested in the end user |
25 |
> packages that often documentation says to install using `npm install |
26 |
> -g` (which I never do); packages that are useful for command line |
27 |
> generally. I have resorted to using nvm for a few reasons: ease of |
28 |
> use, compatibility, testing, and the fact that nodejs is not slotted |
29 |
> in the Portage tree. Even if Gentoo had slots for nodejs/npm, it |
30 |
> would not make it easier to test against different versions the way |
31 |
> nvm does. In particular with time some versions would go away before |
32 |
> other distros upgrade. |
33 |
> |
34 |
> Your eclass kind of does something, as far as i can tell, which is |
35 |
> very discouraged. Line 84 shows it downloading the dependencies with |
36 |
> npm install to create sort of a separate root of the package, and |
37 |
> then you generate a script to launch with the correct environment |
38 |
> variables (and yes you avoid getting stuff already on the system). |
39 |
> It's like nvm but done with Portage, but for each package. Users are |
40 |
> not in control of the ebuild if they cannot specify how things get |
41 |
> downloaded (make.conf can customise the command). NPM_DEFAULT_OPTS |
42 |
> does not document how one could add proxy options. Even if you undid |
43 |
> the npm install by invoking the user's command to download the |
44 |
> packages, it would still not be acceptable as packages must be able |
45 |
> to live in distfiles. I also do not see what you are going to do when |
46 |
> package1 is already installed depending on dep1 version 1.2 but now |
47 |
> package2 wants to be installed wanting dep1 on version 2.2. Automagic |
48 |
> slotting? |
49 |
|
50 |
The idea is that as first step I create manually dependencies of every |
51 |
package/ ebuild and where is available a system package I use |
52 |
NPM_SYSTEM_MODULES to exclude module from install. I know, it isn't a |
53 |
fine solution but as I wrote I want create a module that try to create |
54 |
ebuild automatically from package.json and when I do that I can avoid |
55 |
to use npm install on src_prepare phase. |
56 |
For now on src_prepare I use npm install to download dependencies with |
57 |
exact version match (I add -E option on NPM_DEFAULT_OPTS for do this). |
58 |
About your question for dependencies conflits (and slotting) is equal |
59 |
to a normal package. See you packages about Openstack project where |
60 |
Juno release has a lot of dependencies restrictions like package1 |
61 |
>=1.2, package <= 2.2. |
62 |
Yes, I know that is not easy to maintain ebuilds upgraded but like |
63 |
happens now in a lot of gentoo ebuilds, if a project is not more |
64 |
maintained (and so it isn't usable with more updated dependencies) is |
65 |
removed from portage. |
66 |
|
67 |
|
68 |
> |
69 |
> > |
70 |
> > ...like for perl I think that manage nodejs modules as gentoo |
71 |
> > package is more clear than use directly npm features. |
72 |
> |
73 |
> I kind of disagree. The current state of nodejs packaging just does |
74 |
> not allow for easy external packaging except for basically what you |
75 |
> are doing which is using npm install, or vendoring every package to |
76 |
> avoid conflicts. |
77 |
> |
78 |
> You must get the individual packages and set up separate ebuilds and |
79 |
> they must be able to share dependencies in most cases. The problem is |
80 |
> the contents of package.json is often to just get 'the latest' |
81 |
> version of every dependency or extremely incompatible versions. The |
82 |
> community is moving too quickly for Portage to always be up-to-date |
83 |
> with this. |
84 |
|
85 |
I do not agree with this, I think that manage nodejs module inside |
86 |
Portage is possible, not easy, but possible and more easy to manage |
87 |
instead of npm command. |
88 |
There is same problem with perl modules, CPAN normally has more updated |
89 |
modules but currently ebuild about perl modules are present. |
90 |
About your comment for 'the latest', normally FWIS dependencies are |
91 |
with version with (~) that it's means get the latest or same version, |
92 |
but with -E option to npm command you can force use of same versions. |
93 |
|
94 |
> |
95 |
> The same problem exists with Java packages that use Maven for |
96 |
> dependency management. It is almost as bad as Go, but the importance |
97 |
> of some Go packages (Docker) is outweighing the complexity of |
98 |
> reverse-engineering the `go get` mentality of that community. They |
99 |
> basically do not want users to not use `go get` if it's available. |
100 |
> They really want users to stick to their language-specific package |
101 |
> managers. As a result of the Go unpredictability with versions, there |
102 |
> are plenty of projects that 'vendor' their dependencies including |
103 |
> Docker. |
104 |
> |
105 |
> https://gist.github.com/datagrok/8577287 |
106 |
> |
107 |
> In particular, Python and Ruby seem to have settled versioning a lot |
108 |
> more. Most packages do not specify Git repositories @ HEAD or any |
109 |
> strange things like that. Releases get made in a predictable manner |
110 |
> for the popular packages, because the consumers demand stability and |
111 |
> predictability. (Ruby is not non-guilty, take a look at Vagrant.) |
112 |
> |
113 |
> Also line 236: |
114 |
> |
115 |
> npm_pkg_mods=( $(ls --color=none node_modules/) ) |
116 |
> |
117 |
> This should be npm_pkg_mods=( node_modules/* ) (and then call |
118 |
> basename on each when iterating). |
119 |
|
120 |
Thank you for your suggestion, but with npm_pkg_mods=( node_modules/* ) |
121 |
if there aren't directories under node_modules on variable is then |
122 |
present an entry with node_modules/*, instead if I use ls an empty row |
123 |
is returned. |
124 |
|
125 |
> |
126 |
> Andrew |
127 |
> |
128 |
> |
129 |
|
130 |
In conclusion, it seems that is not accepted use of nodejs modules |
131 |
ebuild inside portage. It is right? |