7 ms·
I’m not OP but: When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requireme
by __full_pint 7y ago
I’m not OP but:
When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build.
Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.
- erikpukinskis 7y agoBut you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?
- __full_pint 7y agoOf course you do that type of testing. The problem comes about when someone does the following: - creates python project - pip install some_package - import some_package Turns out some package was already in the path but a different version - proceeds to test and build with the assumption of some_package @ newer - all tests pass - ships project with requirements of some_package @ newer Someone attempts to use the package but it doesn’t work.
- erikpukinskis 7y agoRight, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment? That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs. But maybe I’m not understanding your suggestion.
- __full_pint 7y agoOP was referring to containerizing your environment for package development. What does connecting to a production DB have to do with any of that?