contains-io / containment Goto Github PK

We need to test, and handle this.

The containenv init and contain commands must be implemented in a sufficiently modular fashion to allow different underlying container types.

To begin with the functionality of each command should be implemented in rkt and docker.

I'll do docker if @dangle does rkt...

This issue is complete when (pytest) tests exist that validate correct operation of the parser.

Cases covered should (at a minimum) include:

• missing preferences.ini
• missing section headers (various types)
• section types not available
• malformed section contents (what does this mean)?

Note we don't necessarily need to recap tests of the basic parsing functionality.

• add travis-ci badge
• do slack channel magic (slackin) and add badge
• explain branching (all work happens off development; master is for releases ONLY)
• design stuff in #3

This step requires a proper "FROM" directive which MUST reference the correct image tag from the earlier steps in containenv init.

We need tests that validate file equivalence "inside" and "outside" the container.

This issue is complete when the specification of the preferences file (1.0) is complete, a parser has been implemented, tested, and documented.

The spec should include (at a minimum):

• more than 1 example "preferences.ini" file
• A first-draft list of ini heading "technologies", e.g. ".py", ".js",...
• An abstract specification of section names
• a vocabulary for discussing the components of the file

All of the above in some clear readable, format/location

• mount $HOME:$HOME (this allows us to use the .bash_profile/.bashrc customizations, i.e., make inside the container feel and look like outside the container)
• entry point will be a script that:
  • accepts a set of env variables from the RUN script and sets them internally
  • creates the right users, groups, and IDs
  • ???

Things to be addressed later:

• mounting $HOME can make docker builds too big and unwieldy
• security issues (from others and from self)

Currently, the code parses the subcommands from the docstring of the subcommand. Instead, it should use an argument in the primary command to specify the subcommand, as in the docopt git example.

There are two sources of configuration information:

(0) CORE: (version 0.1) inferred from project stored as: PROJECT/.containenv/Dockerfile
(1) SUGGESTED_PREFERENCES: (version 0.2) in PROJECT/.containenv/SUGGESTED (overridden by PREFERENCES)
(2) PREFERENCES: (version 0.1) ${HOME_ENV}/containenv/preferences.ini

Containenv has the task of providing an all-in-one sandbox that seamlessly fulfills all the necessary functions for a given software project.

We need a howto that says: Do x, Do y, now you are at the edge of containenv funcitonality.

Then people need to start walking through it, and making it (the howto) better, and filing issues which need to be added to the backlog.

Right now, containenv only works on projects that already exist in some fashion. containenv should support any project, from the beginning of development until the end.

Both contain and containenv need to perform common operations. These operations are now methods of the utils.CommandContext class.

virtualenv is for python projects.
Our alternative should, initially, inherently support python (3), go, & node.js. Other languages can be added later.

We should have a slack channel that reports the results of all CI events.

One of the most basic patterns of virtualenv users is:

virtualenv [TARGET_DIR]
[cd TARGET_DIR] source bin/activate

this becomes:

containenv [TARGET_DIR]
[cd TARGET_DIR] containenv activate

We need to figure out how we want to handle docs.
@zancas

After init completes, there should be a PROJECT containenv image published in a consistent location.

For now containenv simply has an Init_Command.proj_path string reference... this may not be sufficient in the near future.

[PROJECT]/.containment/Dockerfile should be the Single Source Of Truth for the most recently activated containment

This allows the git-like subcommand pattern to be easily implemented.

So, the project is already there... containenv should have explicit tools that manipulate state in this case. e.g. Maybe you know that the new ubuntu from image is different in some desirable way. Perhaps containenv should provide a convenience flag to allow you to force a rebuild.

This process will be more natural once containenv init is broken into natural constituents:
containenv init write_config and containenv init build and containenv init publish perhaps?

This issue is closed when theres a succinct explanation of the preferences.ini file, including:

• design
• contents
• how to modify
• how it's used.

First off we need at least one email address just for containenv.

This issue is complete when there is (Python) code that consumes the .ini file and produces appropriate data structures, for other subsystems to consume.

I'm following @dangle 's cli from ver testenv project so I'm going to use docopt instead of argparse.

Containenv should autodetect the architecture for the images used in FROM. (e.g. running on an RPi).

Alternatively, it could default to multiarch images: https://hub.docker.com/u/multiarch/