I have seen a very nice thing in the js framework este (
https://github.com/Steida/este).
What he does there, he basically has a file watcher and whenever his style
changes,
it is compiled with stylus, whenever his coffee script changes, it gets
translated to
js, whenever his js changes, tests are run.
I have started implementing this by copying pserve.py into my project and
enhancing
its file monitor with a possibility to have a callback, which is called
every second.
In this callback I (conditionally) compile my styles, and run unit tests.
It's working
nicely, but I have doubts whether this is the best way to go about it -
meaning
extending pserve. I somehow feel, that maybe this is not the right task for
pserve,
and I should do it the other way round - implement my own file monitor,
which will
control the restarting of my pyramid app, and compiling files and running
tests. I will
be greatful for any opinions.
(I know about fanstatic and pyramid_fanstatic. Good for resource inclusion,
but not
what I seek for the less/stylus-->css.)
On 4 November 2012 20:29, Petr Blahos <petrbla...@gmail.com> wrote:
> What he does there, he basically has a file watcher and whenever his style
> changes,
> it is compiled with stylus, whenever his coffee script changes, it gets
> translated to
> js, whenever his js changes, tests are run.
You could have a look at miracle2k/webassets or tav/assetgen.
Both have pyramid integration projects and both handle content-hash-based
automatic recompilation.
On Sun, Nov 4, 2012 at 11:29 AM, Petr Blahos <petrbla...@gmail.com> wrote:
> Hi all,
> I have seen a very nice thing in the js framework este (
> https://github.com/Steida/este).
> What he does there, he basically has a file watcher and whenever his style
> changes,
> it is compiled with stylus, whenever his coffee script changes, it gets
> translated to
> js, whenever his js changes, tests are run.
> I have started implementing this by copying pserve.py into my project and
> enhancing
> its file monitor with a possibility to have a callback, which is called
> every second.
> In this callback I (conditionally) compile my styles, and run unit tests.
> It's working
> nicely, but I have doubts whether this is the best way to go about it -
> meaning
> extending pserve. I somehow feel, that maybe this is not the right task
> for pserve,
> and I should do it the other way round - implement my own file monitor,
> which will
> control the restarting of my pyramid app, and compiling files and running
> tests. I will
> be greatful for any opinions.
> (I know about fanstatic and pyramid_fanstatic. Good for resource
> inclusion, but not
> what I seek for the less/stylus-->css.)
> Cheers,
> Petr
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
> On 4 November 2012 20:29, Petr Blahos <petrbla...@gmail.com> wrote:
> > What he does there, he basically has a file watcher and whenever his
> style
> > changes,
> > it is compiled with stylus, whenever his coffee script changes, it gets
> > translated to
> > js, whenever his js changes, tests are run.
> I was thinking about using good old makefile, together with an approach
like
you mentioned. Simply: something changed? make. It has to run on Windows
though (I have no choice). I know there is make on windows too, but it
complicates
matters enormously.
--
Petr
> You could have a look at miracle2k/webassets or tav/assetgen.
> Both have pyramid integration projects and both handle content-hash-based
> automatic recompilation.
webassets look good. Somehow it feels better than fanstatic. Now I am
starting to
thing in a different direction, which is: If I am in a debug mode, I will
start a thread
directly in my pyramid app (probably in a modified pyramid_webassets),
which will
take care of the periodic compilation of the resources. Meaning, not when
they are
required, but when sources change (based on a set of bundles defined in
webassets).
On Mon, Nov 5, 2012 at 1:08 PM, Petr Blahos <petrbla...@gmail.com> wrote:
> You could have a look at miracle2k/webassets or tav/assetgen.
>> Both have pyramid integration projects and both handle content-hash-based
>> automatic recompilation.
> webassets look good. Somehow it feels better than fanstatic. Now I am
> starting to
> thing in a different direction, which is: If I am in a debug mode, I will
> start a thread
> directly in my pyramid app (probably in a modified pyramid_webassets),
> which will
> take care of the periodic compilation of the resources. Meaning, not when
> they are
> required, but when sources change (based on a set of bundles defined in
> webassets).
> Thanks for your pointers.
> --
> Petr
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
On Mon, Nov 5, 2012 at 11:17 AM, Michael Merickel <mmeri...@gmail.com>wrote:
> I believe pyramid_webassets + webassets already handles compiling sources
> for you based on the filters you define within each bundle.
It's true. I'm using webassets today in this way. When configured in debug
mode, it should compile assets as needed, when sources change, on every
page load. Combined with `pserve --reload`, to restart the paste server
when python files change, it makes for a very low-friction development
workflow.
> On Mon, Nov 5, 2012 at 1:08 PM, Petr Blahos <petrbla...@gmail.com> wrote:
>> You could have a look at miracle2k/webassets or tav/assetgen.
>>> Both have pyramid integration projects and both handle
>>> content-hash-based automatic recompilation.
>> webassets look good. Somehow it feels better than fanstatic. Now I am
>> starting to
>> thing in a different direction, which is: If I am in a debug mode, I will
>> start a thread
>> directly in my pyramid app (probably in a modified pyramid_webassets),
>> which will
>> take care of the periodic compilation of the resources. Meaning, not when
>> they are
>> required, but when sources change (based on a set of bundles defined in
>> webassets).
>> Thanks for your pointers.
>> --
>> Petr
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-discuss" group.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pylons-discuss+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pylons-discuss?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
we use fanstatic and less in our pyramid application. both things are great (though i don't know about webassets yet).
first we had the ``lessc`` in pyramid as explained here: http://www.gawel.org/weblog/en/2011/12/Using_lesscss_with_pyramid_and... this has several disadvantages: - compilation of a ``less`` file to ``css`` causes the app to restart, as lessc is run on start (too slow)
- lessc must be in the path when starting the app; useless restriction on a production machine and a little hazzle in a buildout environment with self-built nodejs
- no option to add another build-step like compressing the ``css`` files
we dropped the solution above and i just built a simple nodejs script that watches our files and compiles on demand (really short latency, no app restart). this watcher is automatically started in the local ``supervisord``, which is configured by buildout. on production there is no lessc or anything nodejs-related.
fanstatic itself - just to mention that - is great for us because of the excellent resource handling and the ability to package and version static files on production.
> You could have a look at miracle2k/webassets or tav/assetgen.
> Both have pyramid integration projects and both handle content-hash-based automatic recompilation.
> webassets look good. Somehow it feels better than fanstatic. Now I am starting to > thing in a different direction, which is: If I am in a debug mode, I will start a thread
> directly in my pyramid app (probably in a modified pyramid_webassets), which will
> take care of the periodic compilation of the resources. Meaning, not when they are > required, but when sources change (based on a set of bundles defined in webassets).
> Thanks for your pointers.
> --
> Petr
> -- > You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
