ops(build): replace template symlink with copy

symlinks break wheel creation after all

Author: jannismain

.gitignore

@@ -10,3 +10,5 @@ __pycache__
 build
 .obsidian
 docs/examples
+src/init_python_project/template
+src/init_python_project/copier.yaml

Makefile

@@ -111,12 +111,19 @@ PKGNAME=init_python_project
 PKGDIR=src/${PKGNAME}
 BUILDDIR?=build/dist
 PYTHON?=python
-build: ## build package
+TEMPLATE_SRC?=./template
+TEMPLATE_DEST?=${PKGDIR}/template
+build: copy-template ## build package
 	@${PYTHON} -m pip install --upgrade build
 	@${PYTHON} -m build --outdir ${BUILDDIR} .
 install-build: build
 	@pip uninstall -y ${PKGNAME}
 	pip install --force-reinstall ${BUILDDIR}/*.whl
+copy-template:
+	@cp -r ${TEMPLATE_SRC} ${TEMPLATE_DEST}
+	@cp copier.yaml ${PKGDIR}/.
+build-clean: ## remove build artifacts
+	rm -rf ${BUILDDIR} ${PKGDIR}/template ${PKGDIR}/copier.yaml
 
 
 .PHONY: help

noxfile.py

@@ -5,30 +5,33 @@
 
 nox.options.reuse_existing_virtualenvs = True
 nox.options.stop_on_first_error
-nox.options.sessions = ['build', 'test']
+nox.options.sessions = ["build", "test"]
 
-source_directories = ('src')
+source_directories = "src"
 
-supported_python_versions = ['3.11']
+supported_python_versions = ["3.11"]
 
 root = pathlib.Path(__file__).parent
-build_dir = root/"build"/"dist"
+build_dir = root / "build" / "dist"
+
 
 @nox.session
 def build(session: nox.Session):
     if build_dir.is_dir():
         shutil.rmtree(build_dir)
     build_dir.mkdir(parents=True, exist_ok=False)
 
-    session.run('make', 'build' , external=True, env={'BUILDDIR': str(build_dir)})
+    session.run("make", "build", external=True, env={"BUILDDIR": str(build_dir)})
 
 
 @nox.session(python=supported_python_versions)
 def test(session: nox.Session):
     """Run all tests against dev and target environment."""
-    wheel_files = sorted(build_dir.glob('*.whl'))
+    wheel_files = sorted(build_dir.glob("*.whl"))
     print(wheel_files)
     assert len(wheel_files) == 1, "a single wheel should have been built"
     wheel_file = wheel_files[0]
     session.install(f"{wheel_file}[test]")
-    session.run('pytest', '-k', 'test_package', *session.posargs, env={'BIN_PATH': str(session.bin)})
+    session.run(
+        "pytest", "-k", "test_package", *session.posargs, env={"BIN_PATH": str(session.bin)}
+    )

src/init_python_project/copier.yaml

@@ -0,0 +1,170 @@
+_subdirectory: template
+
+project_name:
+  type: str
+  help: What is the name of your project?
+  placeholder: Sample Project
+  expected: Title case string, can contain spaces
+  explanation: |
+    The project name will be used to propose a suitable package name and [Remote Url][remote-url].
+    It is also repeated in multiple places (Python package configuration, documentation, etc.).
+
+package_name:
+  type: str
+  help: What is the name of your Python package?
+  default: "{{ project_name|lower|replace(' ', '_')|replace('-', '_') }}"
+  expected: Lowercase string, can contain underscores
+  explanation: |
+    This is the name of your Python package. As such, it will be used as the name of the directory containing your code.
+    All imports of your package start with this name.
+
+    Example: If you choose `sample_project` as your package name, your code files would be created in
+
+    ```
+    ./
+    ├── src
+    │   └── sample_project
+    │       ├── __init__.py
+    │       ├── __main__.py
+    │       └── some_module.py
+    ├── pyproject.toml
+    └── ...
+    ```
+
+    and your imports would look like this:
+
+    ```python
+    from sample_project import some_module
+    ```
+
+    You might want to consult [PEP 423 – Naming conventions and recipes related to packaging](https://peps.python.org/pep-0423/)
+    for guidance on Python package name conventions.
+
+    The cli command included with this template will be named after your package, only with dashes instead of underscores.
+    Following the example above, your cli would then be available as
+
+    ```console
+    $ sample-project --help
+    ```
+
+    If you ever want to publish your Python package to [PyPI](https://pypi.org), the package name has to be unique to be accepted there.
+
+    Finally, the package name is repeated across multiple configuration and documentation files.
+
+use_precommit:
+  type: bool
+  default: true
+  help: Use pre-commit to run checks on each commit?
+  explanation: |
+    [pre-commit](../reference/tooling/pre-commit.md) is a tool that makes configuring [git hooks][git-hooks] a lot easier.
+
+    This template uses pre-commit hooks to ensure, all changes match the expected formatting and style.
+    Additionally, running linters at this stage can prevent committing something that contains obvious issues.
+
+    Most formatters and some linters are able to fix issues automatically.
+    So you can simply review the changes those tools made, stage them and commit again.
+
+use_bumpversion:
+  type: bool
+  default: false
+  help: Use bumpversion to manage semantic version across multiple files?
+  explanation: |
+    If you want to version your project, [bumpversion][] provides an easy way to increase version numbers across multiple files.
+
+    It integrates with git and helps with your release workflow by automating version bump, commit and tag creation.
+    Used correctly, releasing a new version of your project can be done with a single command.
+
+    It also helps to follow [semantic versioning][semantic-versioning] guidelines when increasing your version numbers.
+
+docs:
+  type: str
+  choices:
+    Material for MkDocs: mkdocs
+    Sphinx: sphinx
+    None: none
+  default: "mkdocs"
+  help: Which documentation tool do you want to use?
+  explanation: |
+    [Documentation][documentation] is an important part of any project.
+
+    So far, this template supports two documentation tools: [MkDocs][mkdocs] and [Sphinx][sphinx].
+
+    [MkDocs][mkdocs] is a great documentation tool built around [Markdown][markdown].
+    It is easy to use and produces a great looking documentation website with minimal overhead and configuration.
+
+    [Sphinx][sphinx] is a powerful tool for documentation written in [Markdown][markdown] or [reStructuredText][restructuredtext].
+    With the [`myst_parser`][myst_parser] it is now (almost) possible to rely on Markdown only.
+    Choose this if you want to publish your documentation in multiple formats (e.g. PDF, HTML, ePub, ...).
+
+    If you are not sure which one to use, simply go with the default 😉.
+
+remote:
+  choices:
+    GitHub: github
+    FHG Gitlab: gitlab-fhg
+    IIS Gitlab: gitlab-iis
+  help: Which platform will your project be hosted on?
+  default: "github"
+  explanation: |
+    This template provides a CI configuration for either GitHub (Github Actions) or GitLab (Gitlab CI).
+
+    Also, the link to your documentation depends on which remote you choose.
+
+    If you want to push your project to multiple remotes, you can add them later.
+
+user_name:
+  type: str
+  help: User name (the one you used with your hosted git provider)
+  explanation: |
+    This is the user name you are using with the remote provider you provided in the previous question.
+
+    Together with [remote][], it will be used to suggest a [remote url][remote-url] for your project.
+
+remote_url:
+  type: str
+  help: URL of the remote repository
+  default: git@{% if remote=='github' %}github.com{% elif remote=='gitlab-iis' %}git01.iis.fhg.de{% elif remote=='gitlab-fhg' %}gitlab.cc-asp.fraunhofer.de{% endif %}:{{user_name}}/{{project_name | lower | replace(' ', '-')}}.git
+  expected: SSH URL to your remote repository
+  explanation: |
+    Apart from configuring the git remote for you, the remote URL is required to determine other values, such as
+
+    - Links in your README and CHANGELOG files
+    - Links to your documentation
+    - Link to your repository from your documentation
+    - ...
+
+    If you did not create your remote repository yet (i.e. new project at GitHub or Gitlab), this might be a good time to do so.
+
+    !!! tip "Create empty repository"
+
+        Do not initialize your remote project with a LICENSE or README file.
+        This will let you push your initial commit without merge or rebase.
+
+    === "Gitlab"
+
+        ![](https://cln.sh/gwzwgtHH+)
+        *The SSH URL to your Gitlab repository can be found under the `Clone` dropdown (screenshot taken 23.08.23)*{.caption}
+
+
+    === "GitHub"
+
+        ![](https://cln.sh/SscJVB6N+)
+        *The SSH URL to your GitHub repository can be found under the `<> Code` dropdown menu (screenshot taken 23.08.23)*{.caption}
+
+default_branch:
+  type: str
+  default: main
+  help: Name of the initial git branch that will be created
+  expected: Lowercase string, can contain dashes
+  examples: [main, master, dev]
+  explanation: |
+    Name of the [initial branch][] of your new project.
+
+    This branch traditionally was called `master`, but is more often called `main` now.
+
+    [initial branch]: https://git-scm.com/docs/git-init#Documentation/git-init.txt---initial-branchltbranch-namegt
+_tasks:
+  - "rm -rf context"
+  - "git init --initial-branch={{default_branch}}"
+  - "git remote add origin {{remote_url}} || true"
+  - "{% if use_precommit %}pre-commit install || echo 'Error during installation of pre-commit hooks. Is pre-commit installed?'{% endif %}"