Is single source constraint hard?

[autotaker]

I looked Dockerfiles in this repository and find that
only single source is copied into container image.

Current submission system favors specific languages that have ability to pack multiple sources into single source (for example, JavaScript)

Is the single source constraint hard?
If so, is there any restriction on the size of the main source?

[autotaker]

If there is no size restriction,
players may compile their sources (written in any languages) to WebAssembly and include it in main.js.

[beevee]

No, single source constraint is not hard.

Due to my lack of experience with the majority of requested languages, I was able to write only the most basic Hello world example. You are free to send a PR that lifts the single file constraint for your favorite language.

[beevee]

There is no hard size restriction on repository right now.

As expected, if a team's submission becomes too much of a challenge for our build system (hours of build time, gigabytes of binaries, etc.) we reserve a right to enforce some sensible size restriction before or during the contest.

[autotaker]

You are free to send a PR that lifts the single file constraint for your favorite language.

This is a very good news. Thank you.

Yet, I'm afraid that there will be a "war" of choosing build tools and libraries.
There are a number of build toolchains for each language and
it's a kind of each team's preference which tools and libraries are used.

Instead of submitting PR, how about each team publishing their favorite docker image (for building their source code) on public repository (for example DockerHub)?

[beevee]

If there is any disagreement between teams in terms of build tools, we can always make a "fork" (e.g. two "languages" called haskell-stack and haskell-cabal).

We considered letting teams use any Docker images they like, but decided against it mostly because of submission system stability, performance and security. We need to keep limited number of small base images to benefit from caching. We need to have control over these images to prevent frequent changes that break things during the contest.

[autotaker]

If there is any disagreement between teams in terms of build tools, we can always make a "fork" (e.g. two "languages" called haskell-stack and haskell-cabal).

How about libraries?
Each team will use a different set of libraries, including them all will cause dependency hell.

I expect that eventually each team will create their fork of build base image.
Then, your requirement:

We need to keep limited number of small base images to benefit from caching

is infeasible.

[beevee]

Each team will use a different set of libraries

Knowing the nature of the task, I really don't expect that.

Adding libraries to base image is reserved for languages with a very limited standard library. Any specific dependency you should just embed into your source code.

[autotaker]

Knowing the nature of the task, I really don't expect that.

Okay, I believe you.

Adding libraries to base image is reserved for languages with a very limited standard library. Any specific dependency you should just embed into your source code.

What do you mean "embed into your source code"?
Is it okay to embed third-party library artifacts (such as jar file or tar file) in our repository?

[beevee]

Is it okay to embed third-party library artifacts (such as jar file or tar file) in our repository?

Yes, it is okay to put anything you like in your repository.

As long as you don't break any licenses and your submission build time is under 10 minutes, including shallow repository cloning time. So, please don't put Blu-ray disk images in your repo, but otherwise you can submit anything you want.

You can probably even take base python image and write a simple script that launches an included precompiled binary.

[autotaker]

You can probably even take base python image and write a simple script that launches an included precompiled binary.

It is great news!
Now my concern is disappeared.
I'm really looking forward to the contest!
Thank you for the information.

[last-g]

This literally means that nothing except python/bash is usable and build step is rather a fiction.
It's not possible to use C++ platform because:

1. you are limited to header only libraries
2. compiler flags are necessary for any compilation and there is no universal set of flags that will fit every team

I really appreciate that you tried to make it easy for beginners and made it easy in the very basic case but, unfortunately, this setup is not friendly to any other case and anything more complicated than "hello world".

E.g. You mentioned that I'll have to communicate over HTTP. In python where the HTTP client is present in standard library it's quite low-level and not easy to use. This means I'd want to use requests library but this will require some non-trivial machinery to just setup the environment. And another team decide to use aiohttp so you can not just add requests to a main Dockerfile for everyone because you will need to add every possible library I might want to use.

And a kind reminder that git in its basic nature is not good at storing and manipulating multi-megabyte blobs.

Why not just allow to submit docker images and/or use custom docker files?

cc: @beevee

[last-g]

We considered letting teams use any Docker images they like, but decided against it mostly because of submission system stability, performance and security. We need to keep limited number of small base images to benefit from caching. We need to have control over these images to prevent frequent changes that break things during the contest.

You still can keep a limited amount of allowed base docker images and just allow to customize the the last layer as the user wants. It's much better for caching compared to storing blobs in git.
Providing an ability to submit images will address all the stability and security concerns for you and will allow you to save some servers used for the build farm.

cc: @beevee

[last-g]

I'm also a bit concerned about amount of burden that will fall on the organizers team once the contest begin and contestants realize what do they miss from the build/submission system.

cc: @beevee