Open Stack

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 possible to have both configurations
for grunt and pyscss ?
3. Packaging - again - 'uglifyng' some scripts and css to make packages
contain ready for production static files.


This seems like quite work to prepare the whole environment, but will it
work for the needs we have?


On Thu, Jan 15, 2015 at 10:12 AM, Tihomir Trifonov <t.trifonov at gmail.com>
wrote:

> 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
> Bower - will use Bower, that's mostly for development, and whoever prefers
> pip - will use pip. Ideally, it seems fine to have the static files into
> separate git repo(s), as it is now in XStatic.
>
> I'll try to make an (incomplete or maybe not so correct) list of the
> stages a static file goes through:
>
> 1. Development - all we need is versions of uncompressed js and css files.
> We can
>
> On Thu, Jan 15, 2015 at 12:05 AM, <david.comay at oracle.com> wrote:
>
>> 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 platform.
>>>
>>
>> Not to belabor the thread, but yes, of course JavaScript is very
>> relevant to Oracle, Solaris, our customers/partners, etc. And that
>> includes both client and server-side. As Drew stated, as of this moment
>> we haven't yet made Node.js available on SPARC but I expect that to
>> change in the future. But the question or potential concern remains as
>> to whether adding a non-Python/pip build dependency makes sense.
>>
>> 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 during the build process is an
>> interesting build detail. I thought the intent of the XStatic work was
>> to provide Python wrappers around the various JavaScript libraries so
>> they could be pulled down via pip. Since there's already a Python
>> requirements.txt file for versioning information, that seemed to be a
>> nice way of indicating which versions of the JavaScript libraries could
>> be used by Horizon and Python was used all the way through the build.
>>
>> I realize that it takes work to build the XStatic packages but given
>> the Python packages are basically wrappers, it seems creating those and
>> uploading them to pypi could be automated by using Bower and setup.py
>> but perhaps translating the metadata isn't straightforward.
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Tihomir Trifonov
>



-- 
Regards,
Tihomir Trifonov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150115/3b7cc542/attachment.html>