GitMate.io thinks a possibly related issue is #57 (closed) (contributors cron failing with following error).
GitMate.io thinks a possibly related issue is #57 (closed) (contributors cron failing with following error).
GitMate.io thinks possibly related issues are #2 (closed) (Add database file to .gitignore), #61 (closed) (Replace new db.sqlite3 to old db.sqlite3 which contains bears data), #15 (closed) (.gitignore: Remove migrations folder and add bear migrations), #7 (Add Teams), and #49 (closed) (Add teams to Contributor model).
GitMate.io thinks possibly related issues are #101 (closed) (ExecutableRequirement doesnt support .bat/.cmd), #31 (Support OneGet), #15 (Support SnapCraft), #29 (NuGet support), and #67 (closed) (Support Haskell stack).
GitMate.io thinks possibly related issues are #77 (closed) (Template for .coveragerc), #93 (closed) (Sync artwork), #56 (closed) (Sync Moban), #90 (Create LICENSE templates), and #2 (closed) (Create .editorconfig template).
GitMate.io thinks possibly related issues are #18 (closed) (Follow-up from "appveyor.yml.jj2: Add template for appveyor config"), #37 (closed) (Add support for documenting multiple packages), #93 (closed) (Sync artwork), #56 (closed) (Sync Moban), and #103 (closed) (Build breakage in GitLab test environment on python:2.7-alpine).
GitMate.io thinks possibly related issues are #96 (closed) (GitLab CI: Add retries), #73 (closed) (Create gitlab-ci.yml template), #94 (closed) (GitLab CI: use extends), and #18 (closed) (Follow-up from "appveyor.yml.jj2: Add template for appveyor config").
GitMate.io thinks possibly related issues are #5 (Testing mechanism), #45 (closed) (Allow projects to skip tests), #83 (closed) (test file glob), #100 (closed) (Add ipdb to test-requirements.txt), and #20 (closed) (Add moban for test-requirements.txt).
GitMate.io thinks possibly related issues are #39 (closed) (Update test-requirements.txt with pytest-timeout breakage), and #50 (closed) (Handle building documentation when setup.py
is absent).
We have a PR in coala which makes one section depend on a dotfile in ~ , which is not ideal, and causes gitmate to go nuts if missing.
Rather that needing perfect ideal setup, which requires patches to linter and bears, it would be nice to disable sections that would otherwise fail on gitmate . A safety workaround for similar problems.
Hey, this issue has been closed because the label type/feature
is set and there were no updates for 60 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
GitMate.io thinks possibly related issues are #52 (closed) (Add py36 to Appveyor), #49 (closed) (Add prof to gitignore), #78 (closed) (New variable for coverage threshold), #20 (closed) (Add moban for test-requirements.txt), and #96 (closed) (GitLab CI: Add retries).
GitMate.io thinks possibly related issues are #20 (closed) (Add moban for test-requirements.txt), #40 (closed) (Add packaging pin to test-requirements.txt), #70 (closed) (Ignore pip 18.0 in test-requirements.txt), #66 (closed) (Add test requirement pytest-travis-fold), and #39 (closed) (Update test-requirements.txt with pytest-timeout breakage).
GitMate.io thinks possibly related issues are #3 (Create a README.rst template), #60 (closed) (Create README.rst for this repository), and #92 (closed) (Improve README).
GitMate.io thinks possibly related issues are #97 (Add SVG and CSS version of coala-header), #14 (closed) (Import templates from upstream), #61 (closed) (unused import in setup.py), and #32 (Import conf.py from upstream).
Currently, settings are applied via environment variables. This is bad.
http://movingfast.io/articles/environment-variables-considered-harmful/
While this is good enough when running in Docker. It is a pain when running it outside of Docker. This kills portability.
It also kills potential features like a proper "admin area" where the settings can be applied from the site itself or a "setup" page for more user friendliness.
It also kills operators use of existing automation tools such as Chef, Puppet, etc.
Currently, we're using settings.py
to store the settings in Python. Since it's part of the actual program instead of a simple text-file loaded by the program. It is possible settings.py
can be malicious. Not to mention by doing this we ignore a lot of tests and moving part of the source code is awful when having it stored inside a data folder to run the program like when it's installed as a proper python/distribution package.
I'm proposing to have a simple directory location to store settings. This directory can by default be $(pwd)/settings/
and for simplicity I think Python's built-in configuration format is good enough for what we need.
The text files in the settings
can simply be treated as if they're combined into one file. Priority of the files can be simply be done by sorting the filenames, for example 00-base.ini
, 01-database.ini
. 01
is bigger than 00
so changes/variables made in 01
will be more important and change the ones on 00
By doing that, the configuration made by the potential Admin area can be simply applied as a file containing the settings which will be the last one loaded/applied.
Hey, this issue has been closed because the label type/feature
is set and there were no updates for 60 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
GitMate.io thinks possibly related issues are #19 (Investigate using sarge), #59 (closed) (Add ask_yes_no function to Question.py), #58 (closed) (.gitignore: Use moban to generate this), #55 (closed) (Build appveyor.yml using moban), and #66 (closed) (Use single quotes in setup.py).
GitMate.io thinks a possibly related issue is #79 (ask_yes_no arg default should accept bool).
GitMate.io thinks a possibly related issue is #29 (closed) (Spelling correction Trimms to Trims in docstring).