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 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 surf
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 t
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 automatic
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
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
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
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina 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 may be fine on a
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.
[...]
http
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.
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 Matth
Radomir Dopieralski 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
>> the Angular pa
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
Matthias Runge 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
>> underst
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 packa
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
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 conne
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
Matthias Runge 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 juno
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
Radomir Dopieralski 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 the
>>> Java
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 p
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 specific
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 Wed Jan 21 2015 at 7:00:12 AM 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 Debia
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 usi
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 th
> On Jan 16, 2015, at 12:55 PM, 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
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
exam
> On Jan 16, 2015, at 11:33 AM, Drew Fisher 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 original technica
>
> 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 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 spec
> On Jan 15, 2015, at 7:27 PM, Michael Krotscheck 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 to support/
>
> > 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 aroun
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 d
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 p
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
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 p
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.
>
> > 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 co
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
> devel
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
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 poi
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 wrote:
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 f
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 pa
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 a
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
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 t
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 p
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 lo
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 onl
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
> known
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. Up
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 til
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" wrote:
>On 06/01/15 01:39, Tripp, Travis S wrote:
>> What Rado
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.
s?
>
> Thanks,
> Travis
>
> From: Richard Jones mailto:r1chardj0...@gmail.com>
> >
> Reply-To: OpenStack List openstack-dev@lists.openstack.org>>
> Date: Monday, January 5, 2015 at 2:08 AM
> To: OpenStack List mailto:openstack
> -d...@lists.openstack.org&g
k List
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
mailto:open
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
wrote:
> On 05/01/15 00:35, Richard Jones wrote:
> > On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
> > mailto:openst...@sheep.art.pl>> wrote:
> >
> > On 20/12/14 21:25, Richard Jones wrote:
> > > This is a good proposal, though I
On 05/01/15 00:35, Richard Jones wrote:
> On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
> 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 populated by a d
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
bow
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
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 man
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 changes
66 matches
Mail list logo
