Merge pull request #5 from pyiron/add_yml

add yml file

docs/README.md

@@ -1,114 +1,40 @@
-# pyiron_module_template
+# Stinx
 
 ## Overview
 
-This repository is a template for new pyiron modules similar to the existing modules of the 
-pyiron framework, e.g. 
-[pyiron_workflow](https://github.com/pyiron/pyiron_workflow),
-[pyiron_ontology](https://github.com/pyiron/pyiron_ontology),
-etc.
+Stinx is a sibling repository of the DFT code [Sphinx](https://sxrepo.mpie.de). It provides the python parser to generate the input files for the Sphinx code.
 
-Within this repository, the new module is called `pyiron_module_template` which should be renamed to `pyiron_IntendedModuleName`. 
-This can be easily achieved by modifying and running `bash ./update_module_name.sh` script.
+## How to use
 
-The licence is free to choose, but as a default the BSD3 licence packed here.
+Stinx's input parser is created from the yaml-file located at `src/input_data.yml`. The input file is generated by `src/generator.py`. You can use the parser via:
 
-## Continuous Integration
-
-We collect all files relevant for the continuous integration (CI) pipelines in `.ci_support`, 
-while the actual CI workflows are handled by GitHub and stored in `.github`.
-If you are cloning this template *inside* the pyiron GitHub organization, the full CI should work out-of-the-box by calling reusable workflows from [pyiron/actions](github.com/pyiron/actions) and inheriting organization-wide secrets.
-Otherwise, you will either need to modify the CI workflow files, or give your repository the following secrets:
-- `DEPENDABOT_WORKFLOW_TOKEN` (GitHub token for an account that has permissions to your repository -- needs to differ from the default `github_token` already available though! In pyiron we have a special [@pyiron_runner account](https://github.com/pyiron-runner) for this purpose.)
-- `PYPI_PASSWORD` (Token generated on PyPi to give access to your account there)
-- `CODACY_PROJECT_TOKEN` (Token generated on Codacy to give access to your account there)
-
-Make sure to go to [Codacy](https://www.codacy.com) and [Coverall](https://coveralls.io) to register your repository.
-
-The default CI setup from [pyiron/actions](github.com/pyiron/actions) makes some assumptions about your directory structure.
-The most important one is that your environment should be specified in `.ci_support/environment.yml`.
-There is a base environment there already, giving dependence on `pyiron_base`.
-The CI will automatically keep environment files read by readthedocs (which will look at `.readthedocs.yml`) and MyBinder (which looks in `.binder`) up-to-date based on this environment file.
-
-In case you need extra environment files for some setups, you can modify the workflows in `.github/workflows`, which accept input variables for the docs, tests, and notebooks environments.
-For example, it's typically good to not make your project depend on the `lammps` package, since this is not available for windows.
-However, you might want to give some demo notebooks that run on MyBinder (a linux environment) and use LAMMPS calculations.
-In this case, you could add a new file `.ci_support/environment-notebooks.yml`, and then edit `.github/workflows/push-pull.yml` so that instead of reading 
-
-```yaml
-jobs:
-  pyiron:
-    uses: pyiron/actions/.github/workflows/[email protected]
-    secrets: inherit
-    # All the environment files variables point to .ci_support/environment.yml by default
+```python
+from stinx.input import sphinx
 ```
 
-It instead reads
+This instance `sphinx` is used to create all possible input classes for Sphinx by choosing the class via dot-notation and call `create`. For example in order to generate the class `kPoints`, you can run:
 
-```yaml
-jobs:
-  pyiron:
-    uses: pyiron/actions/.github/workflows/[email protected]
-    secrets: inherit
-    with:
-      notebooks-env-files: .ci_support/environment.yml .ci_support/environment-notebooks.yml
+```pythoon
+kPoints = sphinx.basis.kPoints.create()
 ```
 
-Where `.ci_support/environment-notebooks.yml` looks like:
+You can find the input in the parent class, i.e.:
 
-```yaml
-channels:
-  - conda-forge
-dependencies:
-  - lammps
+```python
+basis = sphinx.basis.create(kPoints=kPoints)
 ```
 
-### Dependencies
-
-The CI for making new releases expects all the `pyproject.toml` dependencies to be fully specified with `==` and the conda dependencies to have their versions specified by `=`, i.e. precisely specifying the version the code here is intended to run on.
-At release time, these dependencies can be relaxed so that new users installing your code may have access to a wider variety of environment possibilities.
-For exact details on this relaxation, check documentation in the [centralized CI](https://github.com/pyiron/actions).
-
-### Label-based CI
-
-Some CI triggers when labels get applied to a PR. 
-In a new repository, you will need to define these labels:
-- `format_black`: Runs black analyis and creates a bot-generated commit to fix any format violations
-- `run_CodeQL`: Runs the external CodeQL analysis (expensive, only do at the end)
-- `run_coverage`: Run all the tests in `tests` and use coveralls to generate a coverage report (also expensive, only run near the end of your PR)
-
-## Documentation
-
-You should modify this README to reflect the purpose of your new package.
-You can look at the other pyiron modules to get a hint for what sort of information to include, and how to link badges at the head of your README file.
-
-At a minimum, we suggest creating a meaningful example notebook in the `notebooks/` directory and creating a MyBinder badge so that people can quickly and easily explore your work.
-
-You can also edit the docs for your package by modifying `docs/index.rst`.
-By default, this README is used as the landing page, and a simple API section is automatically generated.
-
-## Tests
-
-There is space for "benchmark", "integration", and "unit" tests in the `tests/` directory, with dummy tests for each.
-These are run by the default CI, so modify them to suit your needs.
-
-Additionally, the standard CI will attempt to execute all notebooks in the `notebooks/` directory.
-See [`pyiron/actions`](https://github.com/pyiron/actions) and the reusable workflows there to learn about modifying the environment for the CI, e.g. to use a different env for notebook runs than for the tests in `tests/`.
-
-Finally, `tests/integration/test_readme.py` shows how example code in the documentation gets tested against its claimed output.
-E.g. if you change this:
+Finally, you can translate it into the Sphinx format via:
 
 ```python
->>> print(2 + 2)
-4
+from stinx.toolkit import to_sphinx
 
+sphinx_input = to_sphinx(basis)
 ```
 
-To read `5` instead, those tests should fail.
-
-## Publishing your package
-
-If you are inside the pyiron organization or have your own `PYPI_PASSWORD` secret configured, your package will be published on PyPI automatically when you make a new "release" on GitHub -- *as long as* that tag matches the pattern specified in `setup.cfg`; by default any tag that `pyiron_module_template-`, where `pyiron_module_template` is replaced with the name of your module. We recommend using semantic versioning so that your first release looks like `pyiron_module_template-0.0.1`.
+You can then write it to a file via:
 
-Releasing your package on Conda-Forge is slightly more involved, but not too hard (at least for pure python packages).
-See [conda-forge/staged-recipes](https://github.com/conda-forge/staged-recipes) for how to publish it there.
+```python
+with open('sphinx.in', 'w') as f:
+    f.write(sphinx_input)
+```