Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add an edit-mode option #421
Test will indeed require a bit of thought. Some ideas below.
What do you think of using the tests from #413 (https://github.com/jupyter/repo2docker/pull/413/files#diff-73b9b926dafec45bd12128b598a0dd45) as a starting point?
I was thinking if we can execute
I've put the documentation as a FAQ (even if it isn't (yet)), since I'm not sure how well it fits as a how-to. And I didn't see documentation on the individual options (other than what argparse produces on the command line, obviously).
Also: I can't tick the check-box :-(
I seem to have hit a little snag: I can't bind an external volume to an internal volume using an internal variable. I'd like to bind to
I've been looking at another way to work around this, or find a configuration option to change this, but no luck so far. Would anyone know how to do this?
(to be clear, I'd like to do:
I think we could resolve
I'd be Ok with having the docs say "Editable mode is a convenience option that will mount the repository to
I have yet to figure out how to resolve
But it looks like using
And the working directory generally appears to be set to
If we can assume this will always be the case for
There may have to be a caveat pointing out this doesn't work for fully customized containers(*), similar to the caveat about mounting to another location in the container (the two caveats would probably go together).
(*) I don't actually know if that's true: can a user's Dockerfile remove/ignore the working directory setting? The failing test case as described below suggests it can.
The thing that bugs me, and led me on this chase to
To resolve that issue, I could
Any thoughts on this?
You could inspect
I think it is fine to assume that
So I would keep the current behaviour and add a test that a
I've added two tests:
The five-line fixture can be replaced by an import once #413 gets merged.
Additionally, I have converted the FAQ from Markdown to reStructuredText, since I wanted an admonition note, which is not possible with Markdown. Perhaps this change should be taken out of this PR and put into its own PR.
Lastly, I was looking for a CHANGES file to add this change, but there isn't any. Perhaps the repository is considered the CHANGES file, but generally, I find a separate file easier to read and spot (important) changes between versions, or bug-fixes.
Having a ChangeLog would be welcome at least by me. We haven't been very disciplined so far so if you oulc get us started that would be great.
Do you have a preferred format? My suggestion would be to start with a style a bit like https://github.com/scikit-learn/scikit-learn/blob/master/doc/whats_new/v0.19.rst#version-0191.
Changing from MD to rst would be ideal in a separate PR so we can keep reformatting separate from content changes.
This test only verifies the option one way: a change inside the container (a new file) is reflected in the local host repository outside the container. A further test where a modification at the host level is reflected in the container, is still neede.
This will test whether an externally (host) created file is seen inside the container. This means starting the container, creating a temporary file on the host, then running a simple verification command (`ls`) to detect the file. Once the temporary file is removed on the host side, it should be removed in the container as well.
The dockerfile test is used by test_editable, but should not be used by the generated tests. Removing the verify script will prevent it being run as part of the generated tests.