Fix devcontainer Dockerfile typo (fixes #3114)

[daltonv]

There was a small typo with the name of the requirements.txt file that prevented the whole image from being built.

Fixes #3114

Proposed Changes

1. Fix the typo in the Dockerfile preventing the build

Readiness Checklist

Author/Contributor

• Add entry to the CHANGELOG listing the change and linking to the corresponding issue (if appropriate)
• If documentation is needed for this change, has that been included in this pull request

Reviewing Maintainer

• Label as breaking if this is a large fundamental change
• Label as either automation, bug, documentation, enhancement, infrastructure, or performance

[echoix]

It's funny that you mention this out, since I've been working around this for the last two days on my fork when fiddling with Megalinter. As I'm often available in the evenings, and I never want to open up my full computer so I can sleep, I like using only my cellphone to keep things limited in scope. I recently learned about CodeSandbox, that also uses the devcontainer specification. It fails to start, just like on Codespaces.

However the devcontainer.json was broken even before the change to have a requirements.txt and a makefile to bootstrap in Gitpod.io (that I also use when on my computer for Megalinter).

For codespaces specifically, I don't agree that a specialized docker image is the best choice for users. Anything other that their base image is charged even when off (when not deleted).
I'm more of the opinion that these kind of devcontainers should more be a standard clean environment that can't be broken by your own project, so its possible to 1) start over cleanly, and 2) know if it is your config/projectvthat is a problem or not.

I honestly think it's better to use something like the universal image, and use the features section of the devcontainer to add python functionality, and maybe then use the makefile structure (that isn't that bad, the automatic help output and autocompletion make it easy) that was contributed to add missing dependencies. That way, the container is already started and we can figure the rest out.

I have a similar opinion about the Gitpod using a specialized Dockerfile instead of a more common base, and since the python 3.11 is a little bit older than 3.11.4-3.11.5-3.11.6, there is a bug in one of the libraries that has a workaround that isn't working. I manually "fixed" it each time by adding the missing packages to use a ppa, then using this python ppa https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa (but installation doesn't work correctly with the state of the image, I have to use --fix-broken, then retry). Then I can use anything. If pyenv wouldn't have to compile python from source, it would have been able to use the repos' .python-version directly and it would have been great, just like stock Gitpod.

Ok, so in a try here https://github.com/echoix/megalinter/tree/edit/devcontainer, I tried moving the existing devcontainer to a subfolder, and creating another one with less options, so it's possible to select which one with "new with options".

Also let's not forget that the images changed, and aren't published through vscode, but as devcontainers. Like https://github.com/devcontainers/images/tree/main/src/python
(See the links at the top of https://github.com/microsoft/vscode-dev-containers/tree/main/containers/python-3)

[daltonv]

To be honest I haven't messed with with codespaces at all, so I'm not sure about the billing story there. It would be worth looking into that later though.

I will update this PR with the inconsistent comment removed, and then I think it is ready to merge.

[echoix]

To be honest I haven't messed with with codespaces at all, so I'm not sure about the billing story there. It would be worth looking into that later though.

I will update this PR with the inconsistent comment removed, and then I think it is ready to merge.

It's alright. It's a great step for now

[nvuillam]

@echoix are we all good here ? :) if so, plz can u merge ? :)

[echoix]

Thanks!