Wanneer u deelneemt aan een teamcodeproject, moeten alle afhankelijkheden zijn geïnstalleerd om de code te kunnen uitvoeren. Over het algemeen deelt u dit in de vorm van een `requirements.txt`-bestand (`pip Freeze > vereisten.txt`) in de GIT van het project. Wanneer u de pakketten uit het bestand op uw lokale computer installeert (`pip install -r vereisten.txt`), zou dit u in theorie in staat moeten stellen om zonder problemen aan het project te werken. Behalve dat er in werkelijkheid vaak compatibiliteitsproblemen zijn: b.v. u heeft al een andere versie van het pakket geïnstalleerd, een pakketversie op uw systeem wordt overschreven met de versie uit `requirements.txt` van het project, wat problemen met afhankelijkheden in andere projecten veroorzaakt, enz.
Een veel voorkomende manier om dit op te lossen is door gebruik te maken van een virtuele omgeving, waarvan de meest bekende conda of de standaard Python-module venv.
Probleem opgelost?
Niet helemaal, in sommige gevallen kan een gespecificeerde pakketversie op basis waarvan de code is geschreven verschillende releases hebben, afhankelijk van b.v. Besturingssysteem. Dit betekent dat als b.v. uw collega Windows gebruikt terwijl u Linux gebruikt, heeft hij mogelijk geen toegang tot exact dezelfde release als u.
De volgende benadering om dit op te lossen is het onderwerp van dit bericht: dev containers, meer specifiek zullen we kijken naar de Visual Studio Code Dev Containers extension.
Wat dit doet is het creëren van een volledig uitgeruste ontwikkelomgeving met een VS Code Server in de vorm van een docker-container.
Hierdoor is uw configuratie vrijwel identiek aan die van uw collega's, waarbij alle pakketten rechtstreeks op een identiek besturingssysteem (container) worden geïnstalleerd. Zelfs de VS Code-extensies die in het project worden gebruikt (bijvoorbeeld een specifieke codeformatter zoals black) kunnen automatisch worden geïnstalleerd. Dit alles helpt om alle tijd die besteed wordt aan het opzetten van een omgeving te elimineren, wat eenvoudig zou moeten zijn, maar vaak hoofdpijn en verloren productieve tijd veroorzaakt.
U kunt er ook naadloos mee schakelen tussen uw gehele ontwikkelomgeving, gewoon door verbinding te maken met een andere container.
De extensie handelt alle instellingen af op basis van een paar configuratiebestanden in een map met de naam `.devcontainer`, dit is voornamelijk het `devcontainer.json`-bestand, dat er ongeveer zo uitziet:
`json
// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/python
{
“name”: “myproject”,
// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
“image”: “mcr.microsoft.com/devcontainers/python: 0-3.11”,
// Features to add to the dev container. More info: https://containers.dev/features.
// Use ‘forwardPorts’ to make a list of ports inside the container available locally.
// “forwardPorts”: [],
// Use ‘postCreateCommand’ to run commands after the container is created.
“postCreateCommand”: “pip3 install –user - r requirements.txt”,
// Configure tool-specific properties.
“customizations”: {
// Configure properties specific to VS Code.
“vscode”: {
“extensions”: [
“ms - vscode.live - server”,
“ms - python.black - formatter”
]
}
}
// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
// “remoteUser”: “root”
}
`
De VS Code-extensie heeft tools waarmee u dit kunt bouwen, maar u kunt ook gewoon Googlen op de onderdelen die u nodig heeft. Bijvoorbeeld de VS Code-extensies zijn gedefinieerd in de VS Code Marketplace en zijn rechtsonder te vinden, onder “Meer info > Unieke identificatie”.
Een probleem dat u kunt tegenkomen, is dat gegenereerde bestanden en plots moeilijker toegankelijk zijn. Hiervoor zijn meerdere mogelijke oplossingen:
- U koppelt een map in uw lokale bestandssysteem aan het bestandssysteem van de docker-container en gebruikt deze om gegevens te exporteren.
- Een betere oplossing, IMHO, is om een extensie te gebruiken zoals b.v. de Jupyter extension.
- Nog een andere optie zou zijn om het te zien als een headless server en een soort fileserver-opstelling of een vergelijkbare meer definitieve oplossing te gebruiken om gegenereerde bestanden te delen.
Om deze tool ten slotte nog nuttiger te maken, kunnen we deze probleemoplossingsmethodologie nog een stap verder brengen door de dev-container in de cloud te hosten. Omdat GitHub Codespaces een voor de hand liggende is.
De extra voordelen zijn:
– Eventuele hardwaregerelateerde verschillen worden geëlimineerd omdat het hele team op precies dezelfde machine werkt.
– GitHub Codespaces biedt een webinterface voor VS Code, naast de mogelijkheid om verbinding te maken met uw lokaal geïnstalleerde VS Code-applicatie.
– Je bent ook niet beperkt tot de rekenkracht van het fysieke apparaat waarop je werkt.
– Het is goed geïntegreerd in GitHub en kan worden gemaakt met behulp van een bestaand `devcontainer.json`-bestand dat aanwezig is in uw GitHub-repository.
Dit betekent dat je in theorie hardware-intensieve berekeningen zou kunnen coderen en uitvoeren op een apparaat zo licht als een iPad (zolang je een actieve internetverbinding hebt). Het betekent ook dat u geen stevig werkstation hoeft te kopen voor al uw teamleden, omdat het zware werk in de cloud wordt gedaan.
Het nadeel is dat de dienst geld kost, het GitHub Codespaces systeem is gebaseerd op rekentijd en opslagdagen. Er is echter een gratis niveau waarbij u x uur CPU-tijd en y opslagdagen gratis krijgt, meer informatie hier.
Ik hoop dat dit bericht sommige mensen heeft kunnen inspireren om verschillende mogelijke oplossingen voor een veelvoorkomend probleem te onderzoeken.
