Goedemorgen,
Ik ben bezig met een (Python) projectje waarbij ik data ophaal uit meerdere APIs en de data samenvoeg in een Azure SQL Server. Ik wil e.e.a. uiteindelijk via github publiceren, dus het is wel handig om de database credentials en API keys e.d. af te zonderen. M'n server, database, username en password komen daarmee in .env.
Voor het bouwen van een connectionstring maak ik gebruik van {ODBC Driver 17 for SQL Server}, maar als een toekomstige gebruiker ooit Driver 18 geïnstalleerd heeft, zal dat misschien ook wel gaan werken. De driver lijkt me daarom meer iets voor een config file i.p.v. een environment variable.
Het resultaat is dat je de connection string dan opbouwt uit een combinatie van config en .env, wat er naar mijn idee wel behoorlijk lelijk uit ziet. Werkt natuurlijk prima, maar het voelt ergens wel aantrekkelijk om die driver maar bij de credentials in .env te zetten zodat alles een beetje bij elkaar staat.
Ik ben nog een beetje zoekende in wat de best practices zijn op het gebied van .env files, config files en hardcoded. Ik verbaas me er soms over hoe druk ik me kan maken over dit soort triviale dingen, maar ben wel benieuwd hoe de meer ervaren programmeurs hier mee omgaan.
Misschien in het verlengde hiervan ook leuk om iets te zeggen over de best practices over het delen van de verwachte opbouw van een .env file (in mijn voorbeeld hierboven verwacht ik bijv. dat .env 'username' verwacht en niet (bijv.) 'dbuser'. Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen of meld je dit in je readme.md / andere documentatie?
Ik ben bezig met een (Python) projectje waarbij ik data ophaal uit meerdere APIs en de data samenvoeg in een Azure SQL Server. Ik wil e.e.a. uiteindelijk via github publiceren, dus het is wel handig om de database credentials en API keys e.d. af te zonderen. M'n server, database, username en password komen daarmee in .env.
Voor het bouwen van een connectionstring maak ik gebruik van {ODBC Driver 17 for SQL Server}, maar als een toekomstige gebruiker ooit Driver 18 geïnstalleerd heeft, zal dat misschien ook wel gaan werken. De driver lijkt me daarom meer iets voor een config file i.p.v. een environment variable.
Het resultaat is dat je de connection string dan opbouwt uit een combinatie van config en .env, wat er naar mijn idee wel behoorlijk lelijk uit ziet. Werkt natuurlijk prima, maar het voelt ergens wel aantrekkelijk om die driver maar bij de credentials in .env te zetten zodat alles een beetje bij elkaar staat.
Ik ben nog een beetje zoekende in wat de best practices zijn op het gebied van .env files, config files en hardcoded. Ik verbaas me er soms over hoe druk ik me kan maken over dit soort triviale dingen, maar ben wel benieuwd hoe de meer ervaren programmeurs hier mee omgaan.
Misschien in het verlengde hiervan ook leuk om iets te zeggen over de best practices over het delen van de verwachte opbouw van een .env file (in mijn voorbeeld hierboven verwacht ik bijv. dat .env 'username' verwacht en niet (bijv.) 'dbuser'. Is het gebruikelijk om een 'sample .env' mee te leveren met de in te vullen variabelen of meld je dit in je readme.md / andere documentatie?