3 ms·
This strategy should be more common! In the source tarball, there should be one main program which you start. The compiling should be an implementation detail o
by vog 11y ago
This strategy should be more common! In the source tarball, there should be one main program which you start. The compiling should be an implementation detail of the main program.
The same for web applications. I never liked the idea of reintroducing a separate build (concat/minify/compress) process whenever the sources change. Instead, the production mode should be as simple as the debug mode: When the main page is requested per HTTP, first rebuild the client JS app as needed, then deliver it to the browser.
Caching the build result should be no different from any other caching of automatically-generated resources.
I use this approach for almost all new software that I write and I'm quite satisfied with that. The main program (e.g. "bin/mytool") is a wrapper shell script or Python script that runs the build as needed, then starts the program. In the simplest case, this is a wrapper around "make && ./run_tool".
Of course, the program should indicate the build with a small message to stderr, especially if the build takes some seconds or more. Moreover, it should be possible to trigger the build individually such that distros can build packages from that. On the other hand, running the program with "-h" or "--help" is a kind of build-only process, too.
- icebraining 11y agoIt's practical, but on the other hand, that goes against the security practice of not allowing the executable zone (be it memory or filesystem) to be writeable. I personally prefer to precompile stuff, even running "python -m compileall" to create .pyc files, to avoid having to keep that path writeable by the user running the program.
- vog 11y agoGood point! However, if you go down that route in a web application, don't forget to pre-compile templates, and do the same for all other cached things that are "code-like". More generall, I find W^X hard to enforce in typical web applications. Sure you can mount directory read-only, disable access to /tmp and observe what happens. But then they might use the database as template cache, or whatever. In most (web) application I'd be happy if they had a central directory where they write stuff into (bonus points for making that directory configurable), instead of scattering generated files all across the source tree.
- dkersten 11y agoI like to write my code to assume that it will run the same on dev and prod, but then precompile/minify prod code as part of the deployment. That is, I like to set it up like you say, but then not rely on it in production. Mainly because I want as few moving parts as possible on prod (especially if it means I don't need dev tools/libs on the production server).
- SixSigma 11y agoBetter to use a file system based file change monitor and a makefile. Statting your file system for changes on every request adds to latency.
- deleted 11y ago[deleted]