Package: drytoml
drytomlKeep your toml configuration centralized and personalizable.Throughdrytoml, TOML files can have references to any content from another TOML file.
References work with relative/absolute paths and urls, and can point to whole files, a
specific table, or in general anything reachable by a sequence ofgetitemcalls, like["tool", "poetry", "source", 0, "url"].drytomltakes care of transcluding the
content for you.Inspired byflakehellandnitpick, the main motivation behinddrytomlis to
have several projects sharing a common, centralized configuration defining codestyles,
but still allowing granular control when required.This is a deliberate departure fromnitpick, which
works as a linter instead, ensuring your local files have the right content.Usagedrytomlhas two main usages:Use a file as a reference and "build" the resulting one:# contents of pyproject.dry.toml...[tool.black]__extends="../../common/black.toml"target-version=['py37']include='\.pyi?$'...# contents of ../../common/black.toml[tool.black]line-length=100$dryexport--file=pyproject.dry.toml>pyproject.toml# contents of pyproject.toml[tool.black]line-length=100target-version=['py37']include='\.pyi?$'Use included wrappers, allowing you to use references in your current configuration
without changing any file:Consider the originalpyproject.dry.tomlfrom the example above, an alternative
usage fordrytomlis shown next. Instead of this:$black.All done! ✨ 🍰 ✨14 files left unchanged.You would run this:$dryblackreformatted /path/to/cwd/file_with_potentially_long_lines.pyreformatted /path/to/cwd/another_file_with_potentially_long_lines.pyAll done! ✨ 🍰 ✨2 files reformatted, 12 files left unchanged.What just happened?drytomlcomes with a set of wrappers whichCreate a transcluded temporary file, equivalent to the resultingpyproject.tomlin the example aboveConfigure the wrapped tool (blackin this case) to use the temporary fileRunblack, and get rid of the file on exit.For the moment, the following wrappers are available (more to come, contributions are
welcome):blackisortflakehell, flake8helled*In the works:docformatterpytestNotesAlthough the flakehell project was archived, we're keeping a fork alive fromhere, availabe asflakeheavenin pypi.SetupPrerequisitesA compatible python >3.6.9[recommended] virtualenvA recentpipInstallInstall as usual, withpip,poetry, etc:pip install drytomlpoetry add drytoml(probably you'll wantpoetry add --dev drytomlinstead)UsageFor any command , run--helpto find out flags and usage.
Some of the most common are listed below:Use any of the provided wrappers as a subcommand, egdry blackinstead ofblack.Usedry -q exportand redirect to a file, to generate a new file with transcluded
contentsUsedry cacheto manage the cache for remote references.FAQQ: I want to use a different key to trigger transclusionsA: In cli mode (using thedrycommand), you can pass the--keyflagcli, to change
it. In api mode (from python code), initializedrytoml.parser.Parserusing a
custom value for theextend_keykwarg.Q: I changed a referenced toml upstream (eg in github) but still get the same result.A: Rundry cache clear --helpto see available options.ContributeStart by creating an issue, forking the project and creating a Pull Request.Setting up the development environmentIf you have docker, the easiest way is to use the provided devcontainer inside vscode,
which already contains everything pre-installed. You must open the cloned directory
using theremote-containers extension.
Just runpoetry shellor prepend any command withpoetry runto ensure commands
are run inside the virtual environment.Alternatively, you can use poetry:poetry install -E devThe next steps assume you have already activated the venv.CommittingCommits in every branch must adhere toConventional Commits.
Releases are done automatically and require conventional commits messages compliance.To validate commits, you can install the pre-commit hookpre-commit install --hook-type commit-msgWith venv activated, you can commit usingcz commitinstead ofgit committo
ensure compliance.Running checksYou can look at the different actions defined in.github/workflows. There are three
ways to check your code:Remotely, by pushing to an open PR. You'll se the results in the PR page.Manually, executing the check from inside a venvFor example, to generate the documentation, check.github/workflows/docs. To run theBuild with Sphinxstep:sphinx-build docs/src docs/buildOr to run pytest, from.github/workflows/tests.yml:sphinx-build docs/src docs/build... etcLocally, withact(Already installed in the
devcontainer)For example, to emulate a PR run for the tests workflow:act -W .github/workflows/tests.yml pull_requestTODOCheck out current developmenthere