When did you plain to merge to master branch ?
Do we have a TODO list of features to perform before ?

Extracted from #1

ISSUE TYPE

• Documentation Report

COMPONENT NAME

CONTRIBUTING.md

AFFECTED VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

Precise that pull requests have to be performed on develop ^^

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

Each kind of packaging must be documented for final users.
Each documentation must describe how to share packaging file (spec, APKBUILD, etc...) with distributions repositories.

Example with alpine linux:

• fork https://github.com/alpinelinux/aports
• propose or update a new package
• etc...

I'm wondering what the rationale is for defining the entrypoints in their own file rather than on the setup.cfg ?

build apk package for alpine linux distribution

Hello guys!

Create this template from scratch is a good point!
We want (@dj4ngo and myself) to help you to introduce standard software behaviors like system packaging management (rpm, deb, etc...).

We can introduce automatic deployment of different kind of packages to the officials packages repositories like alpine linux and others. CI/CD can be used for push package updates automaticaly when a tag are created with synchronized version number anytime and development version. So a fork of main distributions packages repositories (aports)must be created and keep up to date for and push our new versions automaticaly.

Are you interested by this feature?

We can generate explore gitlab official template for try to generate a version of cookiecutter-pypkg compatible with these templates.

CI/CD can help you to generate this custome version without cookiecutter.
In other words we can use CI/CD/cookiecutter for generate a standalone version compatible with gitlab ecosystem and share this on the official gitlab repository. After that all gitlab users can choose our cookiecutter-pypkg directly in gitlab interface.
https://docs.gitlab.com/ee/gitlab-basics/create-project.html