(Thanks, Andrii, for including me in this conversation. You may not have known that I'm subscribed to this forum, so no need to send copies to me.)
Andrii Senkovych <jolly_ro...@itblog.org.ua> writes: > The last command performs the actual building of the python module: > > 1) npm/bower downloads necessary Javascript libraries (download 152Mb > of js libraries in .tar.gz) So, this is a hack to get Python's distutils to effectively depend on some non-Python software. Those who ignore proper dependency management are doomed to re-implement it, badly :-( > 2) the main (minified/uglified) Javascript file is generated > 3) other js/css resources are generated using tools like coffeescript and less > 4) html files are generated as well These three sound like candidates for upstream using a generic build tool like GNU make or one of the Python-based ones (how do we feel about Fabric?). > In the end these files are included in the resulting python module > tarball. It is totally valid python sdist tarball that can be packaged > using ordinary rules of Python packaging. But according to the Debian > policy this tarball cannot be considered as a source tarball since it > contains generated code, minified js/css etc. I've encountered much the same thing, sadly. The result is a lot of busy work to separate the download-source-and-repackage from the build-from-source steps, untangling a lot of what upstream have done. > Thanks to the conversation on IRC with Ben Finney, I've detected some > potential ideas that should be addressed upstream: > > 1) provide valid (from Debian's PoV) source tarball for buildbot_www > Python module A simple start would be a ‘debian/get-foo’ program to download and package the source for the ECMAScript, HTML, etc. More complex measures may be needed, but I'd see how far that takes you first. > 2) have separate source tarball with bundled javascript dependencies > that can be handled by DebSrc 3.0 format as additional upstream > tarball Yes, the output of the above program would be this file. So you'd have it as part of either ‘uscan’ configuration, or as part of a ‘get-orig-source’ target in ‘debian/rules’. > What steps can be done in such case? What can be done better? Please > share your thoughts. I believe, there would appear more similar > projects in the future, so the conversation should be useful for a lot > more people. I think we're going to have to (as the Debian Python community? as the broader Debian maintainer community?) come up with a unified approach to dealing with the rapidly increasing tendency for upstream releases bundling doing this. -- \ “If consumers even know there's a DRM, what it is, and how it | `\ works, we've already failed.” —Peter Lee, Disney corporation, | _o__) 2005 | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7wy55ujdje....@benfinney.id.au
