On 2015-01-23 12:02:19 +0100 (+0100), Matthias Runge wrote:
[...]
I think providing/updating distro packages is quite comparable to
updating pypi packages.
[...]
Within an order of magnitude anyway. The difference is that most
Python module upstream authors do their own packaging for PyPI (for
On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote:
[...]
It would be totally awesome to switch from pip install to using
distribution packages for testing purposes. At least for
dependencies.
[...]
While it seems nice on the surface, the unfortunate truth is that
neither the infra
On Thu, Jan 22, 2015 at 09:18:46PM +, Jeremy Stanley wrote:
On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
[...]
When there is an update to our requirements, such as the recent
version increment in the version of angular used, a new package
version doesn't automatically
On 23/01/15 10:31, Jeremy Stanley wrote:
On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote:
[...]
It would be totally awesome to switch from pip install to using
distribution packages for testing purposes. At least for
dependencies.
[...]
While it seems nice on the surface, the
Radomir Dopieralski openst...@sheep.art.pl writes:
On 22/01/15 11:27, Martin Geisler wrote:
Maybe this is a dumb question, but if there already is a system
package for, say, Angular, why is the XStatic packge needed then?
Could the system package for Horizon not just point directly to where
On 22/01/15 11:27, Martin Geisler wrote:
Maybe this is a dumb question, but if there already is a system package
for, say, Angular, why is the XStatic packge needed then? Could the
system package for Horizon not just point directly to where the Angular
package has put its files?
Yes, that is
On 21/01/15 19:04, Matthew Farina wrote:
Radomir, thanks for adding some clarity. I do have follow-on questions.
In your example the packages are managed by xstatic. The proposal for
horizon, as I understand it, is to move away from xstatic packages and
instead use bower for development and
On 22/01/15 09:48, Radomir Dopieralski wrote:
All of the XStatic packages had to be packaged for the respective
distributions in order to package Horizon. That was a lot of work, but
it has been done my the packagers of the distributions. As far as I
understand, most of those XStatic packages
Matthias Runge mru...@redhat.com writes:
On 22/01/15 09:48, Radomir Dopieralski wrote:
All of the XStatic packages had to be packaged for the respective
distributions in order to package Horizon. That was a lot of work, but
it has been done my the packagers of the distributions. As far as I
On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote:
Has anyone done an inventory of xstatic packages that are
available as system packages? I ask because I started asking these
questions after doing a cursory inventory and finding few xstatic
packages as system packages.
[...]
Radomir and Matthias,
Has anyone done an inventory of xstatic packages that are available as
system packages? I ask because I started asking these questions after doing
a cursory inventory and finding few xstatic packages as system packages. It
appeared to me that the common case was the one
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com wrote:
I would like to add one more nuance to this discussion that I don't
remember seeing.
JavaScript libraries run in web browser in their JavaScript engines (like
v8) rather than on the server. A version of a JS library
I would like to add one more nuance to this discussion that I don't
remember seeing.
JavaScript libraries run in web browser in their JavaScript engines (like
v8) rather than on the server. A version of a JS library may be fine on a
system, without any security issues, but contain browser issues.
Jeremy, thanks for sharing this. I do have a couple more questions and
comments based on this.
When there is an update to our requirements, such as the recent version
increment in the version of angular used, a new package version doesn't
automatically show up as evident from that list. How would
Richard,
I'm quite familiar with node.js and browser development. I think some of
the issue here may be a lack of detailed explanations and assumptions. By
asking questions here I, and some others, have been learning details that
we didn't know before. And, we're getting to follow from the intent
On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
[...]
When there is an update to our requirements, such as the recent
version increment in the version of angular used, a new package
version doesn't automatically show up as evident from that list.
How would that process be kicked
Radomir, thanks for adding some clarity. I do have follow-on questions.
In your example the packages are managed by xstatic. The proposal for
horizon, as I understand it, is to move away from xstatic packages and
instead use bower for development and system packages (for example, debian,
rpm, and
Martin,
django_compressor does handles creating aggregated and compressed files for
you. This isn't quite the same as C programs because it's not just due to
file size. For example, if you have 2 files many browsers will make two
separate connections to get each file. That mean negotiating a
Matthias Runge mru...@redhat.com writes:
On 21/01/15 09:59, Martin Geisler wrote:
This seems to imply that users will download at least one .js file
per dependency.
Not necessarily. We still use django-compressor, which copies all
javascript into fewer files. E.g. here in my untweaked
On 20/01/15 20:58, Matthew Farina wrote:
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked through the Debian
and Ubuntu
On 21/01/15 09:21, david.co...@oracle.com wrote:
As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch
Radomir Dopieralski openst...@sheep.art.pl writes:
On 21/01/15 09:21, david.co...@oracle.com wrote:
As for our work and updates, using system-wide packages is an
excellent solution in this regard, as we get maintenance and updates
for free. For instance, if there is a security issue in one of
On 21/01/15 09:59, Martin Geisler wrote:
This seems to imply that users will download at least one .js file per
dependency.
Not necessarily. We still use django-compressor, which copies all
javascript into fewer files. E.g. here in my untweaked juno environment,
I just get 3 instead of
As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked through the Debian and
Ubuntu packages I couldn't find the libraries horizon is
On Wed Jan 21 2015 at 7:00:12 AM Matthew Farina m...@mattfarina.com wrote:
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked
On 16/01/15 18:55, Matthew Farina wrote:
Doug, there still is one open question. Distributing JavaScript
libraries via system packages is unusual. Because of that, most of the
JavaScript libraries used by horizon don't have existing packages. Who
will create and maintain the packages for these
On Jan 15, 2015, at 7:27 PM, Michael Krotscheck krotsch...@gmail.com wrote:
I think Oracle's got enough money to support Node.js on SPARC.
How is money relevant here?
Well, normally the argument I've received is We don't have the
time/resources/insert-other-fiscally-motivated-reason
On 1/16/15 9:08 AM, Doug Hellmann wrote:
We are, and as this conversation has veered off in a destructive
direction, I think we should back up and look at the compromise Radomir
posted [1] to see if that solves the original technical problem we all have.
Does having the requirements
Does having the requirements specified in a JSON file, without requiring a
specific build tool to install the files, solve the packaging, testing, and
deployment issue on platforms where node.js isn’t supported natively right
now?
We only support what we test. Unless I missed something,
On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote:
On 1/16/15 9:08 AM, Doug Hellmann wrote:
We are, and as this conversation has veered off in a destructive
direction, I think we should back up and look at the compromise Radomir
posted [1] to see if that solves the
Doug, there still is one open question. Distributing JavaScript libraries
via system packages is unusual. Because of that, most of the JavaScript
libraries used by horizon don't have existing packages. Who will create and
maintain the packages for these JavaScript libraries for production? For
On Jan 16, 2015, at 12:55 PM, Matthew Farina m...@mattfarina.com wrote:
Doug, there still is one open question. Distributing JavaScript libraries via
system packages is unusual. Because of that, most of the JavaScript libraries
used by horizon don't have existing packages. Who will create
I think Oracle's got enough money to support Node.js on SPARC.
How is money relevant here?
Well, normally the argument I've received is We don't have the
time/resources/insert-other-fiscally-motivated-reason to support/work on
node. Ergo, money. But then, given Oracle's conduct around the
All we need is to have someone spend some time to make it possible to have
a common meta files(configs, package descriptions, etc.) so that they can
be interchangeable and used by both Bower and pip, e.g. some tool to sync
changes made in one config and adding it to another. Then - whoever prefers
Ops, sent the prev mail before finishing it...
1. Development - all we need is versions of uncompressed js and css files.
We can use bower or pip requirements to get specific versions.
2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or
grunt and to run tests on that. Is is
On 14/01/15 23:05, david.co...@oracle.com wrote:
I'm not particularly well-versed in the Horizon build process so
perhaps I'm way off base. But given that a distribution's Horizon build
package embeds various JavaScript libraries to be used by the browser,
how those libraries are obtained
On 1/14/15 11:49 AM, Michael Krotscheck wrote:
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
I think Oracle's got enough money to support Node.js on SPARC.
How
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
I think Oracle's got enough money to support Node.js on SPARC.
I think Solaris is no longer relevant
I won't stoop to comment on
I won't stop to comment on this statement other than to say Javascript is
quite relevant to Oracle, Oracle's customers, and Oracle's partners.
Your argument is a boondoggle. Refusing to use node because your favorite
platform doesn't support it is not the fault of node.js, it's the fault of
the
On 1/14/15 6:25 AM, Anton Zemlyanov wrote:
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
Solaris 32-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
On 2015-01-14 17:25:46 +0400 (+0400), Anton Zemlyanov wrote:
Solaris is supported by node.js:
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/
node-v0.10.35-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/
node-v0.10.35-sunos-x64.tar.gz
I believe the point
On 01/14/2015 09:14 AM, Matthew Farina wrote:
I think we're discussing two different situations with slightly different
requirements.
First, there is development and test. I believe the stated goal is to have
node.js here. Would an environment not supporting node.js be needed for
I think we're discussing two different situations with slightly different
requirements.
First, there is development and test. I believe the stated goal is to have
node.js here. Would an environment not supporting node.js be needed for
development or testing? Note, the JavaScript under test and to
Solaris is supported by node.js:
Solaris 32-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
Solaris 64-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz
I think Solaris is no longer relevant
On Tue, Jan 13, 2015 at 7:13 PM, Drew Fisher
On 13/01/15 16:13, Drew Fisher wrote:
On 1/13/15 7:59 AM, Jeremy Stanley wrote:
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
On 13/01/15 16:31, Jeremy Stanley wrote:
On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote:
[...]
Why were the libraries ripped from the Horizon codebase in the
first place? It seems to me they belong with the code using it.
I disagree. If those libraries aren't developed as part of
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
deployment.
[...]
A requirement for testing _is_ a requirement for deployment. If it's
not
On 1/13/15 7:59 AM, Jeremy Stanley wrote:
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
deployment.
[...]
A requirement for testing
On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote:
[...]
Why were the libraries ripped from the Horizon codebase in the
first place? It seems to me they belong with the code using it.
I disagree. If those libraries aren't developed as part of Horizon
then they should not be copied into
On 12/18/14 6:58 AM, Radomir Dopieralski wrote:
Hello,
revisiting the package management for the Horizon's static files again,
I would like to propose a particular solution. Hopefully it will allow
us to both simplify the whole setup, and use the popular tools for the
job, without losing
On 12/01/15 21:53, Drew Fisher wrote:
I know I'm very very late to this thread but can I ask why Bower? Bower
has a hard requirement on Node.js which was removed as a dependency in
Havana. Why are we reintroducing this requirement?
For Solaris, a requirement on Node.js is especially
Thanks, Radomir. How much detail from this discussion should be captured in
the blueprint? I'm afraid I'm more familiar with the Python PEP process.
On Thu Jan 08 2015 at 11:38:57 PM Radomir Dopieralski
openst...@sheep.art.pl wrote:
On 06/01/15 01:53, Richard Jones wrote:
I think the only
On 06/01/15 01:53, Richard Jones wrote:
I think the only outstanding question is how developers and
non-packagers populate the bower_components directory - that is, how is
bower expected to be available for them?
I think following the Storyboard approach is a good idea: isolate a
On 06/01/15 18:39, Lin Hua Cheng wrote:
Radomir,
The current version of Angular were using in Horizon still does not have
cookie and mock
packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data
We still need to do it the long way:
1. Update the
On 06/01/15 01:39, Tripp, Travis S wrote:
What Radomir proposes looks like it would greatly ease the process I am still
going through to get the latest angular available to Horizon for current
development. At the time of writing this, I’m still trying to get the
updated library through. I
Radomir,
The current version of Angular were using in Horizon still does not have
cookie and mock packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data
We still need to do it the long way:
1. Update the Angular version in global-requirements
2. Wait
Thanks, Radomir.
I originally started a patch on Horizon and was going to do that, but was
guided to update global requirements first.
I¹ll go ahead and redo that patch on Horizon.
-Travis
On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
On 06/01/15 01:39, Tripp, Travis S
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon
@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack
-d...@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
openst
So just to be clear, as developers we:
1. have a bower.json listing the bower component to use,
2. use bower to fetch and install those to the bower_components directory
at the top level of the Horizon repos checkout, and
3. manually edit static_settings.py when we add a new bower component to
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is populated by a developer (as opposed to a
packager, which you described).
It's not, the developer version is included in the repository, and
simply points to where Bower is
This is a good proposal, though I'm unclear on how the static_settings.py
file is populated by a developer (as opposed to a packager, which you
described).
Richard
On Fri Dec 19 2014 at 12:59:37 AM Radomir Dopieralski
openst...@sheep.art.pl wrote:
Hello,
revisiting the package
Hello,
revisiting the package management for the Horizon's static files again,
I would like to propose a particular solution. Hopefully it will allow
us to both simplify the whole setup, and use the popular tools for the
job, without losing too much of benefits of our current process.
The
66 matches
Mail list logo
