Re: [gentoo-dev] Fw: reviewboard and its bugs

2014-08-20 Thread Jesus Rivero (Neurogeek)
I originally responded to another thread. Here is what I said:

I gave this a try some time ago and was bummed down by some things. I dont
like nodejs enough, and npm devs seems to not care about centrally/globally
installed packages. There are some npm packages that have to be modified so
they can work when globally installed and it gets boring after a while. npm
packages tend to be really small so one package can have a really high
number of deps.

If anybody is interested in this, check out my repo with npm packages[0]
and a really simple g-npm tool[1] to generate ebuilds for them. These tools
might be outdated cause I don't use nodejs anymore and I dont care much
about it.

Feel free to ping me if you have questions.

Cheers,

[0] https://github.com/neurogeek/gentoo-overlay (I might have something
more recent somewhere)
[1] https://github.com/neurogeek/g-npm



On Tue, Aug 19, 2014 at 11:50 PM, Tim Boudreau niftin...@gmail.com wrote:

 FWIW, I suspect npm is here to stay, and it has a facility for installing
 system-wide utilities;  and NodeJS is both usable and convenient for
 system-level scripting which has no connection to webapps, and has the
 ability to build native code that integrates with NodeJS code as well.

 IMO, it would be pretty insane to write packages that duplicate npm
 packages;  support within portage for installing things with it makes more
 sense.  I've occasionally toyed with the idea of a webapp that exposes
 packages in npm as ebuilds and generates the required metadata on the fly,
 so anything in the npm repository would simply *be* a Gentoo package.  Not
 sure the idea is viable, but it might be.  If that existed, and then some
 known-stable subset of packages for which system-wide installation is
 appropriate could be mirrored in the portage tree, that would probably be
 ideal.

 -Tim



 On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY del...@iinet.com.au wrote:



 Begin forwarded message:

 Date: Wed, 20 Aug 2014 08:45:21 +0800
 From: IAN DELANEY idel...@gentoo.org
 To: gentoo-pyt...@lists.gentoo.org
 Subject: reviewboard and its bugs

 cancel the gentoo-python@lists, was intended for gentoo-dev@lists

 The package reviewboard has reached a stage of warranting this
 submission to the ML.  A simple search of reviewboard in bugzilla lists
 a few 'user submitted' bugs and no less than 3 sec bugs. This package I
 added initially because interest was expressed mainly by my final
 mentor and the other (prior) co-maintainer. Because of changes to
 reviewboard upstream, we need a new eclass and category to cater to
 certain js packages.

 Now wishing to re-write all I have already written in the bugs, in
 summary, reviewboard has become unworkable by the developers of
 reviewboard itself going down the path of nodejs. Enter npm.
 npm was an unknown to me until Djblets and django-pipeline ebuilds
 failed due to the absence of UglifyJS and some related js deps.  On
 being informed of ebuilds for this and related deps in the overlay of
 neurogeek, I discovered they required npm which it seems comes in
 nodejs.  The response drawn by fellow devs over npm is in my limited
 experience unprecedented.  The overall reaction was leave it and don't
 go there.  What became apparent from the ebulds in neurogeek's overlay
 was that these deps didn't lend themselves well to writing ebuilds for
 them for portage.  In the overlay there is in fact an npm eclass to
 overseer their installation into the system.

 After some somewhat reluctant discussion of npm in irc, it has at least
 been suggested that the use of nodejs' UglifyJS in django-pipeline
 could be patched out to relieve us all of any reliance or involvement
 of npm to install these js oriented deps.  That has not ofcourse been
 attempted or tested and allows for the probability of breaking Djblets
 and or reviewboard which I suspect has been written by reviewboard
 developers to explicitly depend on and call these deps. The decision it
 seems isn't whether to allows npm into portage, it already comes with
 nodejs correct me if I misunderstand.  The question is whether to
 support this npm installing packages into a gentoo system by ebuilds
 essentially outside of portage.  This requires an eclass and it has
 been suggested a whole new category for portage under which to
 categorise these npm type packages.  Such an eclass has already been
 written, however, that it has never been added to portage along with js
 style packages in the overlay, to me at least, strongly suggests the
 author always had reservations with its addition.

 There is ofcourse the alternative; to write ebuilds to install these
 packages without npm involvement.  This would still require an
 eclass anyway.   Either way, nodejs and java script are totally outside
 the realm of pythonic packages and are therefore outside my realm
 of knowledge and experience.  Reviewboard developers have essentially
 created a huge dilemma for users of reviewboard in gentoo by going
 

Re: [gentoo-dev] Fw: reviewboard and its bugs

2014-08-20 Thread Tim Boudreau
On Wed, Aug 20, 2014 at 11:08 AM, Jesus Rivero (Neurogeek) 
neurog...@gentoo.org wrote:

 I originally responded to another thread. Here is what I said:
 
 I gave this a try some time ago and was bummed down by some things. I dont
 like nodejs enough, and npm devs seems to not care about centrally/globally
 installed packages. There are some npm packages that have to be modified so
 they can work when globally installed and it gets boring after a while. npm
 packages tend to be really small so one package can have a really high
 number of deps.


For NodeJS, the first-class thing is web applications, and as far as their
concerned, the best practice is, if your application uses a library, it
should have its own copy of it. And, for web applications, that *does*
guarantee that you know what version of everything you're deploying, and
allows an application to have dependencies which themselves have
conflicting dependencies - which helps ensure deployment is uncomplicated
and you know what you're deploying.

However, globally installed packages are supported, and are increasingly
important as people discover NodeJS is useful for things that are not
web-application related.  So it seems like something that's not going away,
and sooner or later package managers will have to deal with it.


 If anybody is interested in this, check out my repo with npm packages[0]
 and a really simple g-npm tool[1] to generate ebuilds for them. These tools
 might be outdated cause I don't use nodejs anymore and I dont care much
 about it.


g-npm looks interesting.

-Tim


Re: [gentoo-dev] Fw: reviewboard and its bugs

2014-08-19 Thread Tim Boudreau
FWIW, I suspect npm is here to stay, and it has a facility for installing
system-wide utilities;  and NodeJS is both usable and convenient for
system-level scripting which has no connection to webapps, and has the
ability to build native code that integrates with NodeJS code as well.

IMO, it would be pretty insane to write packages that duplicate npm
packages;  support within portage for installing things with it makes more
sense.  I've occasionally toyed with the idea of a webapp that exposes
packages in npm as ebuilds and generates the required metadata on the fly,
so anything in the npm repository would simply *be* a Gentoo package.  Not
sure the idea is viable, but it might be.  If that existed, and then some
known-stable subset of packages for which system-wide installation is
appropriate could be mirrored in the portage tree, that would probably be
ideal.

-Tim



On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY del...@iinet.com.au wrote:



 Begin forwarded message:

 Date: Wed, 20 Aug 2014 08:45:21 +0800
 From: IAN DELANEY idel...@gentoo.org
 To: gentoo-pyt...@lists.gentoo.org
 Subject: reviewboard and its bugs

 cancel the gentoo-python@lists, was intended for gentoo-dev@lists

 The package reviewboard has reached a stage of warranting this
 submission to the ML.  A simple search of reviewboard in bugzilla lists
 a few 'user submitted' bugs and no less than 3 sec bugs. This package I
 added initially because interest was expressed mainly by my final
 mentor and the other (prior) co-maintainer. Because of changes to
 reviewboard upstream, we need a new eclass and category to cater to
 certain js packages.

 Now wishing to re-write all I have already written in the bugs, in
 summary, reviewboard has become unworkable by the developers of
 reviewboard itself going down the path of nodejs. Enter npm.
 npm was an unknown to me until Djblets and django-pipeline ebuilds
 failed due to the absence of UglifyJS and some related js deps.  On
 being informed of ebuilds for this and related deps in the overlay of
 neurogeek, I discovered they required npm which it seems comes in
 nodejs.  The response drawn by fellow devs over npm is in my limited
 experience unprecedented.  The overall reaction was leave it and don't
 go there.  What became apparent from the ebulds in neurogeek's overlay
 was that these deps didn't lend themselves well to writing ebuilds for
 them for portage.  In the overlay there is in fact an npm eclass to
 overseer their installation into the system.

 After some somewhat reluctant discussion of npm in irc, it has at least
 been suggested that the use of nodejs' UglifyJS in django-pipeline
 could be patched out to relieve us all of any reliance or involvement
 of npm to install these js oriented deps.  That has not ofcourse been
 attempted or tested and allows for the probability of breaking Djblets
 and or reviewboard which I suspect has been written by reviewboard
 developers to explicitly depend on and call these deps. The decision it
 seems isn't whether to allows npm into portage, it already comes with
 nodejs correct me if I misunderstand.  The question is whether to
 support this npm installing packages into a gentoo system by ebuilds
 essentially outside of portage.  This requires an eclass and it has
 been suggested a whole new category for portage under which to
 categorise these npm type packages.  Such an eclass has already been
 written, however, that it has never been added to portage along with js
 style packages in the overlay, to me at least, strongly suggests the
 author always had reservations with its addition.

 There is ofcourse the alternative; to write ebuilds to install these
 packages without npm involvement.  This would still require an
 eclass anyway.   Either way, nodejs and java script are totally outside
 the realm of pythonic packages and are therefore outside my realm
 of knowledge and experience.  Reviewboard developers have essentially
 created a huge dilemma for users of reviewboard in gentoo by going
 electing to use this js 'toolchain'.  While I normally go to any
 lengths to maintain any and all packages within the python realm, this
 reviewboard has gone way beyond that realm. Until this, its
 underbelly was pure python and posed no real problem. Now I have a
 growing and unwelcome list of bugs of this package assigned to me as
 the sole remaining maintainer which are now unworkable.

 The real problem here is that there is an apparent keen set of would
 be users of this package, one of whom is a gentoo dev, who is to be
 found in at least one of those bugs.  To delete or mask the package
 amounts to a clean solution, and also abandons gentoo users looking
 to have the package made work for them.

 In summary, because of changes to reviewboard upstream, we need a new
 eclass and category to write ebuilds to these packages and add them to
 portage.



 --
 kind regards

 Ian Delaney


 --
 kind regards

 Ian Delaney




-- 
http://timboudreau.com