Replace automake toolchain with setuptools #1744
Conversation
TODO: * handle installation of configuration files * handle installation of documentation * ensure NAV knows how to get at its SQL initialization files. * ensure tox config can handle new build system * remove old build system * and probably more...
we only need to assume PATH is set correctly for us.
Also, don't need sass gem now that we use libsass.
…tential directories
A.K.A "Why do we need to fiddle around with shell scripts to do this?". Put daemon start/stop config into a yaml config file, and have the nav.startstop module use that instead, entirely bypassing the ancient shell scripts.
The `validoptions` attribute is never used, so why check it? All of the functionality has been replaced by the nav.config module, so this could be further reduced by removing the unnecessary use of singleton classes (adding memoized functions or something, instead)
Let the user decide, at runtime, instead of being part of the build config, where pid files and log files should be stored by default, and which user daemons should be running as.
and mainly have them let nav.daemon decide where to put their pidfiles (i.e. according to PID_DIR from nav.conf).
There was a problem hiding this comment.
This enormo-PR seems to be mixing up moving from automake to setuptools and refactoring how to read the config. I'm not sure it'll be worth the hassle to split it into two PRs, one for config and one for setuptools, then have the latter depend on the former, but it would satisfy my paranoia and probably be easier to test (and certainly be easier to review!).
| @@ -0,0 +1,5 @@ | |||
| # setuptool_scm takes care of including everything committed to git, while | |||
There was a problem hiding this comment.
Minimal MANIFEST.in good, yes.
How have you checked that you get the files you expect? When tuning MANIFEST.in/setup.py/setup.cfg, I usually do a fake build and diff the dir-listing in both the wheel (zip) and tarball. I keep around a dir-listing of the previous version for this reason.
Would it be worth it to have a build-test?
There was a problem hiding this comment.
I've only made rudimentary checks. In working more with this last week, including sending some upstream PRs to the libsass-python project, it seems the MANIFEST.in may be wholly unnecessary.
We'll see as we attempt to split up this into multiple PRs.
| ] + build.sub_commands | ||
|
|
||
|
|
||
| setup( |
There was a problem hiding this comment.
This is old-style setup.py. New-style is moving all this to setup.cfg and just have
from setuptools import setup
setup()
in the setup.py.
There was a problem hiding this comment.
Aye, but how does that work when we need to customize parts of the build with our own code?
|
I'm going to close this PR and rework it. |
lunkwill42
changed the title
This PR sets out to replace the entire ancient automake-based toolchain for building and installing NAV, with a
setup.pyusing Python'ssetuptools.Some distinct features:
navnamespace,/python/navwas moved to/nav/htdocs/static) have been moved to/nav/web/static/htdocs/sassto/nav/web/sass/templatestonav/web/templates/sql/to/nav/models/sqllibsass, thus removing the requirement to use Ruby as part of the build tool chain.However, I am having various issues with
libsass' integration withdistutils. It doesn't drop the.scssextension from the Sass files, it only appends.cssto the original name, which breaks our web. There also seems to be an issue with howlibsassappends the compiled css files to the distutils manifest, causing installation to fail when building and installing from an sdist tarball (such as undertox).This means the test suite will fail to run atm. We can either work on patching
libsass(for example, see sass/libsass-python#215), or we can forego the attempt and revert to keep integrating a Ruby-based sass compiler in our toolchain.This PR is also partly motivated by dependency hell on Debian for the upcoming 4.9 release, which prompted me to once again research the option to use https://github.com/spotify/dh-virtualenv to include all of NAV's Python dependencies directly in the Debian package. It seems
dh_virtualenvrequires our package to provide asetup.pyfor installation - and so I went down the rabbit's hole....I humbly leave this for review, while I'm off to EuroPython and 3 subsequent vacation weeks...