Kreyrenized!

[Kreyren]

@JesterOrNot Can you elaborate on abstract? I believe that this can be done better ^-^

[JesterOrNot]

@Kreyren I like the emojis, You can make that a user setting to aviod them

[Kreyren]

@JesterOrNot resolved in https://github.com/gitpod-io/dockerfreeze/pull/33/commits/939b4ddc5997886e1db9575184056d23d07caa84

[JesterOrNot]

Thanks, @Kreyren also, I love your commit messages!

[Kreyren]

@JesterOrNot Can you provide requested abstract? Since i am not sure what are you trying to do with this project..

EDIT: well i have an idea, but it's better to ask

[JesterOrNot]

It will scan the Linux environment, find all installed packages in $PATH Copy environment variables into a Docker image that can be used in Gitpod or used to test changes on your dev-env to make sure you don't break your dev-env

[Kreyren]

@JesterOrNot find all installed packages in $PATH

Why PATH? We can track these through package manager which is more reliable i.e output of apt list --installed

or used to test changes on your dev-env to make sure you don't break your dev-env

elaborate?

[JesterOrNot]

What about other Linux distros though alpine uses apk ArchLinux uses pacman What about packages not installed with a package manager etc

[Kreyren]

What about other Linux distros though alpine uses apk ArchLinux uses pacman

pacman has pacman -Qqe

apk has apk info

What about packages not installed with a package manager

Those woudn't be present on the system..

For manual installation i would check directly for the executable on the system.

etc

elaborate

[JesterOrNot]

I.E. Installed from source code, what about the version number how do we copy that? V cannot be installed by a package manager, so how do we install that to the Dockerfile? If not by iterating over $PATH

[Kreyren]

Installed from source code

i would check directly for the executable on the system instead

ideally we should have a database with pathname tracking, but that is pita to do on apt , apk and pacman (woudn't be an issue on portage and paludis which would also provide better system resources management)

V cannot be installed by a package manager,

Takes seconds to make a downstream for something this simple, but for complicated the above applies.

---

Just to clarify:

It will scan the Linux environment, find all installed packages in $PATH Copy environment variables into a Docker image that can be used in Gitpod or used to test changes on your dev-env to make sure you don't break your dev-env

Do you expect an end-user to use this software on gitpod's runtime to make the dockerfile configuration?

[Kreyren]

Reserved for abstract development

[JesterOrNot]

No one would run this program locally and then all of one's tools would be installed in Gitpod

[Kreyren]

No one would run this script locally and then all of one's tools would be installed in Gitpod

ah i see so checking PATH makes sense, but i would also implement a method to capture the supported configuration depending on package manager used and allow the end-user to chose which packages they want to use).

Also same for enviromental variables since end-users could be using something confidential in env vars.

[JesterOrNot]

This isn't only for Gitpod one could use it to make the Dockerfile run it locally, install a package in it that they are afraid might break their dev env and test it

[Kreyren]

What about support for vagrant as well?

I see https://github.com/gitpod-io/gitpod/issues/1265 being implemented through natural evolution of gitpod which shoudn't be difficult to implement alongside of the dockerfile.

[JesterOrNot]

AFAIK we haven't committed to doing this we could maybe make this a command-line flag for dockerfreeze however such a thing would not be hard, but this would be after we finish https://github.com/gitpod-io/dockerfreeze/milestone/1

[JesterOrNot]

And optimized the Dockerfile outputted by dockerfreeze

[Kreyren]

@JesterOrNot

So from current abstract i see that we need a these functions:

1. Detect Kernel used
2. Detect used File system hierarchy (in case end-user is using ostree or custom)
3. Capture executables from the PATH (or windows path?)
4. GUI/TUI to select the expected configuration

for 1 we can use https://crates.io/crates/os-detect

for 2,3 i am proposing implementing these as a custom crate instead of keeping this as modules so that they can be maintained on crates (possible allow outsourcing the function to rustlang community)

for 4 i am not aware of usable crate for GUI in rustlang excluding Piston

Also proposing adding tests and benches, see https://github.com/Kreyren/rustlang-fibonacci/tree/kreyren/case-study-performance-2 which is by 337.47% more efficient with this approach compared to initial in https://github.com/Kreyren/rustlang-fibonacci.

[Kreyren]

Also you are using structopts, do you know about https://github.com/clap-rs/clap ? it may be more efficient to be used here, but i don't have the research on it yet.

EDIT: i would also propose keeping the argument management in the main.rs itself to call mods from there in case there is a better alternative to argument resolution in the future.

[JesterOrNot]

Also, we don't plan on supporting windows for now, as Gitpod does not support windows containers this should be a feature request for later after the MVP is done. Leave the TUI to me. Also, structopt includes clap-rs. I find structopt easier to read and extend.

[JesterOrNot]

One thing that would definitely help, is we need to format the Dockerfile so that it is readable if you run it in Gitpod it creates an unreadable blob for ENV instructions if you could get it to maintain the single layer and make it output a structure like

ENV foo=bar \
    x=y

That would be awesome

[Kreyren]

Also, we don't plan on supporting windows for now, as Gitpod does not support windows containers this should be a feature request for later after the MVP is done

Recommends stubbing windows in that case so that it would be easier to follow up in case someone wants to contribute it. See https://www.gnu.org/prep/maintain/html_node/Platforms.html

It might be worth making logic to capture executables for their export from windows on nix.

I find structopt easier to read and extend.

Do you prefer convenience over optimization?

[Kreyren]

@JesterOrNot Gitpod it creates an unreadable blob for ENV instructions if you could get it to maintain the single layer and make it output a structure like..

Shoudn't be an issue, noted for the time being

---

@JesterOrNot Any special requirements for POSIX? i.e

# Not compatible with POSIX
if [[ true ]]; then printf '%s\n' "hello";fi

# Does the same thing and is compatible with POSIX
if [ true ]; then printf '%s\n' "hello";fi

This shoudn't matter much on cargo, but we can adapt the coding style to be efficient on used storage for example.

[JesterOrNot]

I prefer readability, extensibility, and ease of contribution over minor benches

[Kreyren]

I prefer readability, extensibility, and ease of contribution over minor benches

What about milion benches with readability, extensibility and ease of contribution? :p

[JesterOrNot]

I do not find clap readable or extensible.

[Kreyren]

@JesterOrNot Lets use your method for argument resolution then

[JesterOrNot]

Also what is hadolint?

[Kreyren]

@JesterOrNot Also what is hadolint?

Linting tool for Dockerfiles, see https://github.com/hadolint/hadolint

EDIT: i've added it because i did not know the abstract, though it being useful.

[JesterOrNot]

K, cool

[JesterOrNot]

And what about criterion

[Kreyren]

@JesterOrNot Do you agree with this approach?

https://github.com/gitpod-io/dockerfreeze/pull/33#issuecomment-594033021

I would make a new directory in src/crates/foo and set Cargo.toml to treat foo as new crate through path.

[JesterOrNot]

3 & 4 but alot of what you're talking about are things to do after we finish the MVP

[Kreyren]

@JesterOrNot And what about criterion

It is a benchmarking tool, see https://github.com/bheisler/criterion.rs and original project on https://github.com/Snaipe/Criterion

it makes the output of benchmarks nicer alike following and helps to limit the noise the system makes, see https://github.com/gitpod-io/gitpod/issues/1217

  Compiling csv v1.1.3
   Compiling tinytemplate v1.0.3
   Compiling serde_derive v1.0.104
   Compiling criterion v0.3.1
    Finished bench [optimized] target(s) in 2m 48s
     Running target/release/deps/kreybonacci-62744ab104fcaf79

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/release/deps/main-ce715c17c9d46db8

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/release/deps/fibonacci-d503bbbbcc4d9576
Gnuplot not found, using plotters backend
Benchmarking fibonacci 5: Collecting 1000 samples in estimated 5.0                                                                  fibonacci 5             time:   [2.5810 ns 2.6249 ns 2.6705 ns]
Found 1 outliers among 1000 measurements (0.10%)
  1 (0.10%) high severe

Benchmarking fibonacci 20: Collecting 1000 samples in estimated 5.                                                                  fibonacci 20            time:   [2.3017 ns 2.3143 ns 2.3282 ns]
Found 72 outliers among 1000 measurements (7.20%)
  2 (0.20%) low mild
  31 (3.10%) high mild
  39 (3.90%) high severe

Benchmarking fibonacci 100: Collecting 1000 samples in estimated 5                                                                  fibonacci 100           time:   [2.3156 ns 2.3306 ns 2.3468 ns]
Found 58 outliers among 1000 measurements (5.80%)
  31 (3.10%) high mild
  27 (2.70%) high severe

Benchmarking fibonacci 1000: Collecting 1000 samples in estimated                                                                   fibonacci 1000          time:   [2.3354 ns 2.3517 ns 2.3695 ns]
Found 48 outliers among 1000 measurements (4.80%)
  28 (2.80%) high mild
  20 (2.00%) high severe

[JesterOrNot]

3 & 4 but alot of what you're talking about are things to do after we finish the MVP

[Kreyren]

alot of what you're talking about are things to do after we finish the MVP

elaborate?

[JesterOrNot]

i.e. A TUI can happen after the CLI is done, Vagrant support should be something that comes later, windows support can happen after Linux and MacOS support. Also these discussions should take place in their respective issues

[Kreyren]

A TUI can happen after the CLI is done, Vagrant support should be something that comes later, windows support can happen after Linux and MacOS support

it can happend after, but making the abstract should prevent rewriting and bad design.

[Kreyren]

Also these discussions should take place in their respective issues

I can make these in the issues if you want, but i believe that in-code documentation is better place for this.

[JesterOrNot]

Network lag sorry

[Kreyren]

np on network lag

[JesterOrNot]

We should move these discussions to their respective issues https://github.com/gitpod-io/dockerfreeze/issues/36 https://github.com/gitpod-io/dockerfreeze/issues/7 https://github.com/gitpod-io/dockerfreeze/issues/34 https://github.com/gitpod-io/dockerfreeze/issues/35

[Kreyren]

noted

[JesterOrNot]

So what is left on this PR?

[Kreyren]

So what is left on this PR?

agreenment on the implementation assuming usage of crates for the abstract in https://github.com/gitpod-io/dockerfreeze/pull/33#issuecomment-594033021 as 2,3 and 4 and code style to account for later implementation of vagrant and cross-platform.

[JesterOrNot]

I prefer having WIP features in a separate branch as master will be used in production

[Kreyren]

@JesterOrNot I prefer having WIP features in a separate branch as master will be used in production

I would rather suggest stubbing these in the code itself i.e if the software is used on windows which is not supported -> Export a FIXME message or similar stubbing

[JesterOrNot]

I'd rather have a master branch with working code so CI is run on every commit

[Kreyren]

@JesterOrNot It would be working assuming that it would be expected for it to assert on unimplemented?

[JesterOrNot]

Yes but that would require giving everyone who wants to contribute write access