Proposal for a Consistent Repository Naming Method for Template Instantiation Solutions

[msclock]

Recently, we have been discussing the need for a consistent agreement on the repository naming method for our template instantiation solutions. In order to ensure efficient management and organization of our repositories in the future, I propose that we establish a standard naming convention.

The goal of this proposal is to streamline our repository processes and enhance clarity and accessibility for all team members. By adhering to a consistent naming method, we can avoid confusion, improve searchability, and facilitate seamless collaboration.

I would like to initiate a discussion on this matter to gather your valuable insights and suggestions. Here are a few points to consider:

1. What are the current challenges we face in managing our template instantiation repositories?
2. How can a standardized naming convention address these challenges and improve efficiency?
3. Are there any existing naming conventions or best practices in the industry that we can draw inspiration from?
4. What factors should we consider when designing a naming method? (e.g., project-specific details, versioning, categorization)
5. How can we ensure the proposed naming convention is easily scalable and adaptable for future needs?

I encourage everyone to share their thoughts, experiences, and any relevant examples. Let's work together towards a consensus on the repository naming method that will benefit our team and the overall project.

Thank you for your time and contributions.

[huxuan]

Really appreciate the initiation of this discussion.

Currently we have two main repos: serious-scaffold-python and cpp-scaffold.

IMO, serious-scaffold-python is a little bit long especially when combining with the organization name, for example, when generating a project, the command copier copy gh:serious-scaffold/serious-scaffold-python /path/to/project is a little bit long. For cpp-scaffold, the problem is a little bit generic, unless used together with the organization name.

As we have discussed, we will have bunch of templates by leveraging the multiple templates mechanism.

For Python-only series, what I can imagine is at least three templates:

1. Python Scaffold
2. FastAPI Scaffold
3. PyTorch Scaffold

For Python Binding series, there are at least two categories:

1. C++ Python Binding, but there could be many approaches, for example, Boost.Python, pybind11.
2. Rust Python Bindings, seems pyo3 is the only recommended choice?

Considering our requirements, seems there are two points we need to make decision:

1. Do we want to cover languages other than Python related ecosystem? For example, cpp-only projects, Java projects and even some frontend languages like nodejs projects.
2. Do we want to keep the serious term or something else? Before coming up with the serious idea, I know there is a popular Python Scaffold project naming pyscaffold.

BTW, we also need to check that the package name is available on PyPI.

[huxuan]

Great, then at least we can reach an agreement on the

• ss-python
• ss-cpp

Is that right?

For those combination and frame specific cases, we can just talk by code.

[msclock]

Great, let's move forward.

[huxuan]

BTW, I am trying to ask whether we can have the package name ss-py, If that works, the name will be more consistent as both py and cpp are abbrevations.

[msclock]

Actually, I don't think it is necessary to upload template to official pypi(https://pypi.org/). But there is a test one(https://test.pypi.org/) that is less used by community.🤣 And I can confirm there is no ss-py(https://test.pypi.org/search/?q=ss-py).

[huxuan]

Actually, I don't think it is necessary to upload template to official pypi(https://pypi.org/).

That is a great point! We can even setup a new one for ourselves since there is no distribution demand.
The only problem I can come up with is that some badges may not work then, but that makes our scaffold more robust.