Gaze/prezto
1
0
Fork 0
mirror of https://github.com/sorin-ionescu/prezto.git synced 2025-01-23 07:52:15 +08:00
Code Issues Projects Releases Wiki Activity

Update container-README.md

Browse Source
This commit is contained in:
H-Lo 2019-10-25 13:41:01 -07:00 committed by GitHub
parent 0b1e26065b
commit e4bb17142c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
container-README.md
View File

@ -14,39 +14,43 @@ The container is a basic install of alpine linux, so the image
download is reasonably small
On the container we have a few utilities and additionalsoftware that
prezto has core support for
you can check it out in a snap by doing:
docker pull hlecuanda/prezto-dev:latest
prezto has core support for, and you can check it out in a snap by doing:
```bash
docker pull hlecuanda/prezto-dev:latest
```
once you have the image, create a container from it with:
```bash
docker run -it --rm -h prezto hlecuanda/prezto-dev:latest
```
that will set you on a prompt withing the container with a
That will set you on a prompt within the container with a
vanilla install of prezto.
a development and testing run can be achieved by mounting the stuff
A development and testing workflow can be achieved by mounting the stuff
you're working on to the image's filesystem:
```bash
docker run -it --rm -h prezto \
-v /local/path:/home/prezto \
-v /local/path/zdotdir:/home/preztoa \
-v /local/module-dev-src:/home/prezto/.zprezto/modules/yourmodulea \
hlecuanda/prezto-dev:latest
```
the third volume mapping is particularly interesting. you can
develop on your own machine and environnmen, and when spinning up the
container, your actual source is already in-plase asif installed on a
vanilla prezto install.
develop on your own machine and environnment, and when spinning up the
container, your actual source is already in-plase as if installed on a
vanilla prezto instance
keep in mind that the container are ephemeral, unless you remove the
--rm option which will create new containers each time you run the
`--rm` option which will create new containers each time you run the
command, but the changes to the filesystemwill persist on a container
file that you can later spin up again to re use.
file that you can later spin up again to re-use.
I have found epehermeral containers to be most useful since you get an
untainted, pristine environment for testing every time you spin up the
container.
hope this turns out to be useful.