1 |
FWIW, I suspect npm is here to stay, and it has a facility for installing |
2 |
system-wide utilities; and NodeJS is both usable and convenient for |
3 |
system-level scripting which has no connection to webapps, and has the |
4 |
ability to build native code that integrates with NodeJS code as well. |
5 |
|
6 |
IMO, it would be pretty insane to write packages that duplicate npm |
7 |
packages; support within portage for installing things with it makes more |
8 |
sense. I've occasionally toyed with the idea of a webapp that exposes |
9 |
packages in npm as ebuilds and generates the required metadata on the fly, |
10 |
so anything in the npm repository would simply *be* a Gentoo package. Not |
11 |
sure the idea is viable, but it might be. If that existed, and then some |
12 |
known-stable subset of packages for which system-wide installation is |
13 |
appropriate could be mirrored in the portage tree, that would probably be |
14 |
ideal. |
15 |
|
16 |
-Tim |
17 |
|
18 |
|
19 |
|
20 |
On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY <della5@×××××××××.au> wrote: |
21 |
|
22 |
> |
23 |
> |
24 |
> Begin forwarded message: |
25 |
> |
26 |
> Date: Wed, 20 Aug 2014 08:45:21 +0800 |
27 |
> From: IAN DELANEY <idella4@g.o> |
28 |
> To: gentoo-python@l.g.o |
29 |
> Subject: reviewboard and its bugs |
30 |
> |
31 |
> cancel the gentoo-python@lists, was intended for gentoo-dev@lists |
32 |
> |
33 |
> The package reviewboard has reached a stage of warranting this |
34 |
> submission to the ML. A simple search of reviewboard in bugzilla lists |
35 |
> a few 'user submitted' bugs and no less than 3 sec bugs. This package I |
36 |
> added initially because interest was expressed mainly by my final |
37 |
> mentor and the other (prior) co-maintainer. Because of changes to |
38 |
> reviewboard upstream, we need a new eclass and category to cater to |
39 |
> certain js packages. |
40 |
> |
41 |
> Now wishing to re-write all I have already written in the bugs, in |
42 |
> summary, reviewboard has become unworkable by the developers of |
43 |
> reviewboard itself going down the path of nodejs. Enter npm. |
44 |
> npm was an unknown to me until Djblets and django-pipeline ebuilds |
45 |
> failed due to the absence of UglifyJS and some related js deps. On |
46 |
> being informed of ebuilds for this and related deps in the overlay of |
47 |
> neurogeek, I discovered they required npm which it seems comes in |
48 |
> nodejs. The response drawn by fellow devs over npm is in my limited |
49 |
> experience unprecedented. The overall reaction was leave it and don't |
50 |
> go there. What became apparent from the ebulds in neurogeek's overlay |
51 |
> was that these deps didn't lend themselves well to writing ebuilds for |
52 |
> them for portage. In the overlay there is in fact an npm eclass to |
53 |
> overseer their installation into the system. |
54 |
> |
55 |
> After some somewhat reluctant discussion of npm in irc, it has at least |
56 |
> been suggested that the use of nodejs' UglifyJS in django-pipeline |
57 |
> could be patched out to relieve us all of any reliance or involvement |
58 |
> of npm to install these js oriented deps. That has not ofcourse been |
59 |
> attempted or tested and allows for the probability of breaking Djblets |
60 |
> and or reviewboard which I suspect has been written by reviewboard |
61 |
> developers to explicitly depend on and call these deps. The decision it |
62 |
> seems isn't whether to allows npm into portage, it already comes with |
63 |
> nodejs correct me if I misunderstand. The question is whether to |
64 |
> support this npm installing packages into a gentoo system by ebuilds |
65 |
> essentially outside of portage. This requires an eclass and it has |
66 |
> been suggested a whole new category for portage under which to |
67 |
> categorise these npm type packages. Such an eclass has already been |
68 |
> written, however, that it has never been added to portage along with js |
69 |
> style packages in the overlay, to me at least, strongly suggests the |
70 |
> author always had reservations with its addition. |
71 |
> |
72 |
> There is ofcourse the alternative; to write ebuilds to install these |
73 |
> packages without npm involvement. This would still require an |
74 |
> eclass anyway. Either way, nodejs and java script are totally outside |
75 |
> the realm of pythonic packages and are therefore outside my realm |
76 |
> of knowledge and experience. Reviewboard developers have essentially |
77 |
> created a huge dilemma for users of reviewboard in gentoo by going |
78 |
> electing to use this js 'toolchain'. While I normally go to any |
79 |
> lengths to maintain any and all packages within the python realm, this |
80 |
> reviewboard has gone way beyond that realm. Until this, its |
81 |
> underbelly was pure python and posed no real problem. Now I have a |
82 |
> growing and unwelcome list of bugs of this package assigned to me as |
83 |
> the sole remaining maintainer which are now unworkable. |
84 |
> |
85 |
> The real problem here is that there is an apparent keen set of would |
86 |
> be users of this package, one of whom is a gentoo dev, who is to be |
87 |
> found in at least one of those bugs. To delete or mask the package |
88 |
> amounts to a clean solution, and also abandons gentoo users looking |
89 |
> to have the package made work for them. |
90 |
> |
91 |
> In summary, because of changes to reviewboard upstream, we need a new |
92 |
> eclass and category to write ebuilds to these packages and add them to |
93 |
> portage. |
94 |
> |
95 |
> |
96 |
> |
97 |
> -- |
98 |
> kind regards |
99 |
> |
100 |
> Ian Delaney |
101 |
> |
102 |
> |
103 |
> -- |
104 |
> kind regards |
105 |
> |
106 |
> Ian Delaney |
107 |
> |
108 |
> |
109 |
|
110 |
|
111 |
-- |
112 |
http://timboudreau.com |