Where is the spec for "pack"/starting with pack writing tutorial? and some more pack writing questions

[alonisser]

1. Where is the spec for "pack" Couldn't find one in the docs.

2. I noticed some packs (python for example) have a detect script, while others (javascript) don't . Should I add one in a PR? when is the "detect" being used"

3. As far as I can tell from current packs they don't support multiple language versions, but take latest (python) or latest LTS (node.js) since there are common idioms indicating language version (.python-version, .nvmrc, .node-version) we can detect language version and use the correct DockerFile FROM clause . Would a pr in that direction would be a good idea?

[bacongobbler]

Hey! There’s a few questions here so I’ll try to answer them separately.

1. DEP 003 goes into more detail on the pack format.

2. Thanks for pointing that out. The detect scripts should be removed from the packs as Draft no longer relies on those.

3. That is correct; https://github.com/Azure/draft/issues/509 partially addresses the problem. If you have a good idea on how we can better adapt to different releases please share your ideas here!

[alonisser]

Thanks
about 3. I think #509 is about namespacing different packs for "python" or "nodejs" coming from different pack repositories. But the general use case might have a connection => Why would you have two different "python" packs if not for covering different cases . The issue I'm talking about is about making the actual packs more adaptable to different language version. so Basically this can be approached in two different ways I think:

1. Add data on the actual language version (if applicable) passed to the pack and allow the pack to handle that. I think linguist which from what I understand from the code is the package determining language is not covering this kind of detection and generally is a limited tool for this use case
2. Give the pack access to the actual source code to allow it to do further analysis if needed, And allow the pack to use templating for DockerFile creation (where the difference would probably the exact base image in the FROM clause)

Thoughts? insights? I might be missing lots of things, as I"m new to this codebase

[bacongobbler]

I might be missing lots of things, as I'm new to this codebase

Nope, that summarizes the situation fairly well. :)

Are you looking to choose between minor/patch releases of the programming language, or the major release? I believe either approach may have entirely different approaches to the problem, most notably being that

• for minor/patch releases, a templating/data injection solution could work. I'd be interested in what sort of workflow this would entail for draft create, and if there are alternative approaches (because in a perfect world where everyone writes perfect software with no flaws or bugs, everyone should be on the latest release :P)
• for major releases, I don't think a templating/data injection solution will work in all cases. Entire Dockerfiles may need to change to accommodate the new workflow to install the application. For example Go 1 and Go 2 could have entirely different workflows to install, compile and run the application.

This has been something I've been pondering as well, so any feedback or input on this problem is greatly appreciated.

[alonisser]

In some ecosystem (e.g node.js for example) major versions are the same workflow basically, but even if not (And I don't know if go 1 is in use in new projects, and if go community has a convention of using version file in the repo to help multi language version detection tools like nvm/ pyenv) enough Templating can handle that.

That being said, I was thinking minor/patch versions (in python for example, new language features can be introduced in minor version e.g 3.6 has new features over 3.5)

About draft create:

• If no specific version detected? proceed with latest supported
• If version detected, use it (Optionally allow the user to choose if to use it, but I guess If I hard coded a language version, I knew what I was doing)

[bacongobbler]

And I don't know if go 1 is in use in new projects

Go 2 isn't out yet. I was just using it as a hypothetical question. :)

My only concern going forward is now that means we need to source Docker images that support all releases of every programming language going forward. Taking a look at library/python it only supports 3.4 to 3.7, and we'd really prefer to be on the "default" images providing support for those language stacks rather than supporting that own infrastructure. Given that constraint I'm not sure it's really worth the effort to allow this form of customization, but I'm still interested in hearing about the use cases this would solve.

[alonisser]

Actually I don't think this would need to source multiple docker files. just a simple template in the dockerfile, changing the base "from" , I can understand why this would be problematic to support . For me at least this limits usability of draft only for new projects, while beginning them, and not to help dockerizing my existing projects. Seems draft current main use case is the first. And if I would want something else, I should probably add a custom repo (given the limitations raised in #509 not sure how that would behave)

Thanks for the responsiveness and helpful attitude

[bacongobbler]

No problem! It was nice to pick your brain on this proposal.

The good news is that we haven't released v1.0 yet and we plan to get draft create into a "beta" state by v0.12 (currently targeted around mid-march) so much of the design and scope of draft create is still being discussed, and feedback like this really helps us know if we're solving the right problems, so thank you. :)

For me at least this limits usability of draft only for new projects, while beginning them, and not to help dockerizing my existing projects. Seems draft current main use case is the first.

Yeah in regards to the criticism around draft create being only usable for new projects, I definitely think that's the current limitation of the tool. To be frank I actually dislike the UX around draft create due to its limitations and opinions, but it certainly does solve the problem of "how do I create a new application ready for deployment onto Kubernetes?" fairly well. I'm hoping that after we release v1.0 we might be able to get more feedback from users (like you) with existing applications on Kubernetes and how we can help get Draft into a more usable state for their use cases. Making the tag in the FROM clause in the Dockerfile is definitely one point that will probably come up in more than one discussion.