These are chat archives for evhub/coconut

28th
Sep 2016
Evan Hubinger
@evhub
Sep 28 2016 06:29
@cmirallesp Locally, there are lots of options for Coconut syntax highlighting, including Sublime, Vim, Emacs, and anything that supports Pygments. Remotely, however--like on GitLab--it's a bit harder, since it's not your system anymore. It looks like GitLab uses rouge for syntax highlighting, which doesn't (currently) support Coconut. It seems that rouge is compatible with Pygments, and by default every Coconut installation comes with a built-in Pygments highlighter, so it's possible you could configure it to use that, but I haven't used rouge before so I don't know.
x10an14
@x10an14
Sep 28 2016 20:25
@evhub Heya, I've managed to dockerize the Dockerfiles for Coconut using the Makefile commands, but I'm having a bit of a quandary here. Ideally, the "install requirements for dev" should be the first thing the docker build command does, because the requirements for the development (like pip packages&versions) are less likely to change than the source-code itself.
(A 'change' in the docker build world constituting a change in the filesystem).
I'm not the sturdiest on setuptools (nor Makefiles), but as far as I can tell, there's no easy way to tell the Dockerfile "import these files (necessary for installing dev requirements) and install development requirements; THEN copy over the whole source-code and execute tests/whatever"
Is this something you @evhub (or someone else) could help me figure out? It's not critical, but it'd make the docker images cleaner and more efficient.
Evan Hubinger
@evhub
Sep 28 2016 21:29
@x10an14 I think the standard for pip is at odds with the standard for docker here. The way that pip works, it calls setup.py, which defines both what the dependencies are and what the source code is to install (and thus requires the source code to already be present). Then, pip uses that information to install the dependencies, and then the source. If you wanted to, you could re-implement the logic that setup.py uses to determine which requirements files in the reqs folder to tell pip to install, but while not overly complex (the hardest part would probably just be detecting the current Python version, since different versions have different requirements), I'd rather not have that logic implemented in two places unless it's really necessary. One possible solution is to strike somewhat of a middle ground, and have docker do something like this:
pip install -r reqs/requirements.txt  # universal requirements
pip install -r reqs/requirements-tests.txt  # always necessary to run the tests
make # install the source code as well as any of the more complicated version-specific dependencies we missed above
x10an14
@x10an14
Sep 28 2016 22:14
@evhub Awesome, I'll look into that next chance I get =) I'm currently trying to get alpine to support the dev tools, so as to minimize the dockerized image from 770MB down to 300ish or so (I hope)!
Evan Hubinger
@evhub
Sep 28 2016 22:24
Great, sounds good!
x10an14
@x10an14
Sep 28 2016 23:05
Welp, it's 1AM, and I should've been in bed 2+ hours ago =P x10an14/coconut@98ba55b is as far as I got tonight, with this being a trace of the error I've got. If anyone's got any idea/suggestion of what's missing/going wrong, I'm all ears! (the command is executed as root/sudo).
Evan Hubinger
@evhub
Sep 28 2016 23:17
@x10an14 Looks like a pre-commit error. Installing pre-commit isn't strictly necessary, since it's just a useful development tool, but it'd be nice. I'd suggest raising an issue over at pre-commit.