ansys/ansys-templates

A tool for creating new projects according to Ansys guidelines

ansys-templates's Issues

Investigate failing `tox -e doc` in poetry based template

🐞 Problem

For baked projects using poetry as the build system, if the tox -e doc command installs dependencies from a lock.file it will fail. However, if this file is deleted and the command is executed again (or for the first time), no problem will be raise.

This behavior can better see in the old actions logs:

2022-03-02T10:54:17.6620137Z Installing dependencies from lock file
...
2022-03-02T10:54:19.3240829Z Installing the current project: ansys-product-library (0.1.0)
...
2022-03-02T10:54:20.6137413Z TypeError: entry_points() got an unexpected keyword argument 'group'

Provide basic and advance Python Package templates

The cookiecutter template gives the user the choice of flit, poetry, or setuptools but provides no guidance. Looking through the existing PyAnsys repositories all three project types are represented. Having a consistent standard for all of PyAnsys has huge benefits:

• Once customers are familiar with one project, they can easily use or work on a different one
• Internal Ansys developers can share knowledge and tricks
• Internal Ansys developers can more easily move between products
• Less strain on the PyAnsys team, as they do not have to be experts in all three

With the size of Ansys and the legacy codebases, we unfortunately probably cannot just enforce a single build system. However, we can strongly recommend, and make the tools lead developers to the right choice.

This is a request that the PyAnsys make a strong stance for a single build system and to change the tools to lead the developers to make the right choice.

Add ISSUES templates

🐞 Problem

An interesting enhancement would be to generate a template for requesting new features and reporting bugs.

💡 Solution

These templates need to be implemented in the .github/ISSUE_TEMPLATES/ directory. Templates need to be formatted using Markdown syntax.

Add automatic GH actions update to ansys-templates

📝 Description of the feature

We have recently discovered that you can also automate the update of GH Actions with dependabot!

💡 Steps for implementing the feature

Just placing the following piece of code in dependabot.yml

  - package-ecosystem: "github-actions"
    directory: "/.github"
    schedule:
      interval: "daily"

🔗 Useful links and references

https://github.com/pyansys/pydisco/pull/152

Integrate the API repository template

Description of the feature

The API repository template is an existing cookiecutter template aimed specifically at creating gRPC API repositories. It uses the protoc compilation helper to automatically compile the .proto files to Python files when building the Python wheel. To enable this, setuptools is used for packaging.

It would be useful to include the API template as part of this repository and deprecate the current repo, to aid discoverability and make it clear which is the most up-to-date version.

Steps for implementing the feature

Mostly, I think the current cookiecutter template can be copied into ansys-templates without much modification.

One open question is testing: Currently, the ansys-api-template repository includes tests which check that the protobuf compilation works on the resulting repository.

Since adding tests specific to a given template seems more broadly useful, maybe we should think how to solve this in general (adding some hook mechanism or common layout for tests?).

As this testing setup will take some work, we can consider merging the API template without its accompanying tests at first, and solving the testing requirement in a separate PR.

Useful links and references

No response

Fix Python templates actions

🐞 Problem

• The template for the Python CI does not consider the minimum required Python version.
  For example, consider the case where the users selects Python 3.8 as the minimum required Python for their package. In this case, the CI will execute the style and docs using Python 3.7, which is incompatible with the package.
• pytest-cov needs to be added to requirements_tests.txt
  Otherwise, the actions will fail.

Implement doctest in tox.ini

🐞 Problem
At the moment, the option to run doctests is not implemented within tox.

💡 solution
It would be interesting to include an option to run source code examples within docstrings, like:

tox -e py-doctests`

This option may be combined, leading to:

tox -e py-doctests-cov

So a heavy test suite gets executed.

Use of "i.e." in README.rst

In the README.rst "i.e." (aka "in other words") is used where I think it is meant to be "e.g." ("for example"). Which is a bit confusing.

Default Tox workflow does not integrate with PyCharm well

According to https://www.jetbrains.com/help/pycharm/tox-support.html you can simply right-click on tox.ini and run or debug from there. Unfortunately that did not work for me very well:

According to the documentation, the tree on the left is supposed to expand into each individual test, which would allow me to individually run or debug tests. The tests did run according to the logs on the right.

Additionally, if I set a breakpoint in my code and right-click tox.ini/select to debug, the project runs but the breakpoint is not hit. As it stands I do not seem to have the ability to debug from tox with this setup.

Changing the project name in a Poetry based build difficult

Run:
cookiecutter gh:pyansys/pyansys-template
Accept all defaults except choose Poetry for the build system.
cd pyproduct-library
poetry install
poetry shell
(from inside shell)
pip install -r requirements/requirements_build.txt
pip install -r requirements/requirements_doc.txt
pip install -r requirements/requirements_tests.txt
poetry install
pytest

So far so good.
Edit pyproject.toml and change name= to "ansys-product2-library"
Rename src/ansys/product to src/ansys/product2
Edit tests/test_metadata.py

pytest will now fail because init.py can't find the project metadata

No amount of poetry install or poetry update will fix it.

The only fix I have found so far (there may be many others), is to remove the poetry environment:
exit
poetry env remove 3.7

and start over above from poetry install.

Extra info in the conf.py

Description of the feature

I think we should include 404 and favicon info.

Steps for implementing the feature

# Favicon
html_favicon = "favicon.png"

# notfound.extension
notfound_template = "404.rst"
notfound_urls_prefix = "/../"

I would also add the extension sphinxcontrib-email :

# to ofuscate email links
email_automode = True

Useful links and references

https://github.com/sphinx-contrib/email

Tox returns missing Python interpreter while Python is installed

🔍 Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

🐞 Description of the bug

Tox returns SKIPPED: InterpreterNotFound when running these commands:

• tox -e doc
• tox -e syle

📝 Steps to reproduce

• git clone https://github.com/Solution-Applications/solutions-app-em-nvh-mapper.git
• python -m venv .venv
• .venv\Scripts\Activate.ps1
• python -m pip install -U pip poetry tox
• python -m pip install -r requirements/requirements_build.txt
• python -m pip install -r requirements/requirements_doc.txt
• python -m pip install -r requirements/requirements_tests.txt
• poetry run python -m pip install dist/ansys_solutions_em_nvh_mapper-0.1.dev0-py3-none-any.whl
• tox -e doc
• tox -e style

💻 Which operating system are you using?

Windows

🐍 Which Python version are you using?

3.7

📦 Installed packages

alabaster==0.7.12
ansys-sphinx-theme==0.4.2
atomicwrites==1.4.1
attrs==21.4.0
Babel==2.10.3
beautifulsoup4==4.11.1
bleach==5.0.1
build==0.8.0
CacheControl==0.12.11
cachy==0.3.0
certifi==2022.6.15
charset-normalizer==2.1.0
cleo==0.8.1
clikit==0.6.2
colorama==0.4.5
commonmark==0.9.1
coverage==6.4.1
crashtest==0.3.1
distlib==0.3.5
docutils==0.18.1
filelock==3.7.1
html5lib==1.1
idna==3.3
imagesize==1.4.1
importlib-metadata==4.12.0
iniconfig==1.1.1
Jinja2==3.1.2
keyring==23.7.0
lockfile==0.12.2
MarkupSafe==2.1.1
msgpack==1.0.4
numpydoc==1.4.0
packaging==20.9
pastel==0.2.1
pep517==0.12.0
pexpect==4.8.0
pkginfo==1.8.3
platformdirs==2.5.2
pluggy==1.0.0
poetry==1.1.14
poetry-core==1.0.8
ptyprocess==0.7.0
py==1.11.0
pydata-sphinx-theme==0.9.0
Pygments==2.12.0
pylev==1.4.0
pyparsing==3.0.9
pytest==7.1.2
pytest-cov==3.0.0
pytz==2022.1
pywin32-ctypes==0.2.0
readme-renderer==35.0
requests==2.28.1
requests-toolbelt==0.9.1
rfc3986==2.0.0
rich==12.5.1
shellingham==1.4.0
six==1.16.0
snowballstemmer==2.2.0
soupsieve==2.3.2.post1
Sphinx==5.0.2
sphinx-copybutton==0.5.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==2.0.0
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.5
toml==0.10.2
tomli==2.0.1
tomlkit==0.11.1
tox==3.25.1
twine==4.0.1
urllib3==1.26.10
virtualenv==20.15.1
webencodings==0.5.1
zipp==3.8.1

Test baked project's GitHub actions

🐞 Problem

In order to test baked project's GitHub actions in the current CI pipelines, we considered the usage of act. When using act, all the baked actions succeed.

However, from action logs, some internal error in act related with the checkout of Python actions was caught by the CI.

We tried to manage it by using the boolean operator act || true, so the output could be redirected and then used to look only for tox log errors.

At the moment, we are forced to use baked project's tox environments for testing the baked actions but it would be very useful to replace this workflow with act.

Improve Docker implementation

📝 Description of the feature

Leveraging docker as build agent is a game changer but one should be aware of some common pitfalls regarding the images you use, the caching mechanism, the way you write instructions eg:

• Start with the tiniest image you need
• Gather RUN commands when it makes sense, as each instruction creates an intermediate layer
• Clean up steps
• Use line separator \ to split multiple instructions within a single step
• Smartly order steps to benefit from cache
  • How costly each step is
  • How resilient to change each step is
• Smartly chain stages

💡 Steps for implementing the feature

1. Move from 950+Mo python:3.7 to 200-Mo python:3.7-slim
2. Split multiple commands for clarity
3. Reorganize steps
4. Reorganize stages
5. Keep dockerfile agnostic

🔗 Useful links and references

A quick 101 has been provided here

Enforce EOL character encoding

🐞 Problem

From a private discussion with Hiroki Takezawa, he pointed out this issue: rendered projects have LF (Posix) encoding even if these are generated in a Windows machine (CRLF encoding).

I'm not really sure why nobody else complained about before. I guess one possibility is that modern editors/IDEs may hide or deal with this issue in a smart way, but not sure at all...

💡 Solution

From [cookiecutter 2.X docs], it is possible to enforce new line character in the cookiecutter.json via _new_lines variable. However, it is also stated:

Developers should correctly configure their .gitattributes file to avoid line-end character overwrite by git.

I guess we can always add this last file in the rendered template, it will be the simplest solution.

Investigate auto-push to GitHub

🐞 Problem
As opposed to the deprecated template, ansys-templates does not automatically create a GitHub repository for pushing the generated project.

💡 Solution
One of the ways for creating a new GH repo is to use the gh tool, see https://cli.github.com/manual/gh_repo_create.

I think we could take advantage of the [subprocess] module for calling gh in the background and push the baked project if specified by the user. The following things need to be considered:

• Projects should be "internal/private" by default. This way we prevent accidental pushes to the platform and force a manual input from the users, meaning that there they are conscious of what they are doing.

• How does gh behave with the current security of the PyAnsys organization when it comes to create a new repo?

Add badges for this project and baked ones

📝 Proposal

Badges offer a quick view on some fundamental properties of a project such us supported Python versions, license, code integrity and coverage...

It would be interesting to add support for badges for this project and generated ones.

Change the ansys-sphinx-theme to use Ansys logo

Now that the repo belongs to the @ansys org, we should Aldo force the docs to use the Ansys logo instead of the PyAnsys logo. We should also review the docs to check more references to PyAnsys (e.g. breadcrumbs).

Add GIF of usage

Would be cool for demo purposes if we had a 10 second GIF showing the usage of this tool.

Add template for REST client library

We have nice templates for a bunch of API servers, but none for API clients.

Consider leveraging the work in https://github.com/pyansys/openapi-common and the sketch at https://github.com/pyansys/template-openapi to make standard clients in a repeatable way.

Implement __main__.py

🐞 Problem

The lack of a __main.py__ prevents users from using ansys-templates as a module.

💡 Solution

Simply add this file and point its execution to the ansys.templates.cli:main function.

Render demo files in documentation tabs

🐞 Problem

Although the demo/ branches are useful for having a quick look at how the rendered projects will look like it would be interesting to be able to access those from the project's documentation.

💡 Solution

One approach could be to create a section for each one of the available templates and render a sphinx tab showing each one of the files for such templates. I think this could be done by taking advantage of Jinja2, which can be used at documentation rendering time.

venv line in setuptools template wrong

Create a setuptools based project and the generated README will tell you to:

python -m venv .venv && source venv .venv

This command does not work for me on my system. The correct command is:

python -m venv .venv && source .venv/bin/activate

As an aside: It may be simpler to understand for beginners if you use the command line as such:

virtualenv .venv && source .venv/bin/activate

The generated code is invalid when the library name has a separator

When instantiating a new project with a separator in the library name like this:

plule@LYOPLULE1:~$ ansys-templates new pyansys
product_name [Product]: platform
library_name [Library]: some_lib
version [0.1.dev0]:
short_description [A Python wrapper for Ansys platform some_lib]:
repository_url [https://github.com/pyansys/pyplatform-some-lib]:
Select requires_python:
1 - 3.7
2 - 3.8
3 - 3.9
4 - 3.10
Choose from 1, 2, 3, 4 [1]:
max_linelength [100]:

The source is structured with a folder named "some-lib" (I believe this is invalid in python):

plule@LYOPLULE1:~$ ls pyplatform-some-lib/src/ansys/platform/some-lib/
__init__.py  __pycache__

but the test assumes that the package is "some.lib":

plule@LYOPLULE1:~$ cat pyplatform-some-lib/tests/test_metadata.py
from ansys.platform.some.lib import __version__


def test_pkg_version():
    assert __version__ == "0.1.dev0"

Fix or release documentation

Update the documentation please. Should be python -m pipx install ansys-templates

(py38) tmp $ python -m pipx install pyansys-templates
Fatal error from pip prevented installation. Full pip output in file:
    /home/alex/.local/pipx/logs/cmd_2022-04-15_12.48.27_pip_errors.log

Some possibly relevant errors from pip install:
    ERROR: Could not find a version that satisfies the requirement pyansys-templates (from versions: none)
    ERROR: No matching distribution found for pyansys-templates

Error installing pyansys-templates.
(py38) tmp $ 

Different pyansys advanced template name when using list and new --help

I cannot create a pyansys_advanced with this script. I receive the following error:

(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ ansys-templates new pyansys_advanced
Usage: ansys-templates new [OPTIONS] COMMAND [ARGS]...
Try 'ansys-templates new --help' for help.

Error: No such command 'pyansys_advanced'.

Using pybasic or pyansys works fine.

Shouldn't this repo be called 'pyansys-templates'

🔍 Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

🐞 Description of the bug

I dont know, I think it should be called 'pyansys-templates'

📝 Steps to reproduce

N/A

💻 Which operating system are you using?

Windows

🐍 Which Python version are you using?

3.7

📦 Installed packages

N/A

Add disabling-CI section for concurrent workflows

Description of the feature

It has been recently implemented in PyMAPDL and other PyAnsys repositories a way to cancel ongoing workflows for scenarios in which two consecutive pushes are performed to a branch. In these situations, only the latest workflow should be kept. The oldest one should be cancelled. This can be achieved using concurrency.

Implement in existing template workflow and actual workflow for this repository if not available.

Steps for implementing the feature

See PyMAPDL implementation by @RobPasMue

Useful links and references

Enhance CI

After #8, this became a command line tool shipping in the form of a Python package. This allowed us to:

• Take advantage of documentation.

• Move the use cookiecutter to the backstage so users forget about this tool.

• Begin able to host multiple any kind of template: Python package, Fortran project...

• CI parametrization

This project is expected to growth, so the CI pipelines should be as much parametrized as possible. This will allow to easily modify workflows in the future. At the moment, although slightly parametrized, the last steps of the CI look like this:

https://github.com/pyansys/pyansys-template/blob/6aa45bff18c31bcfc1ff35b11bb686c141d32b15/.github/workflows/ci.yml#L99-L148

Notice that most of the logic is duplicated here. I'm pretty sure this can be simplified taking advantage of the include directive and declaring custom environment variables for each one of the matrix.build-system.

• Include coverage

Including code coverage is a "must have" in this project if we want to make sure that the ansys-templates CLI tool and the different available templates bake properly.

Render demo templates in repo branches

🐞 Problem

As discussed in private meetings, it would be very advantageous to have some rendered version for each template that this tool provides.

💡 Solution

The devised solution was to render each template in its own dedicated branch, so users and developers can have a quick reference on how the baked project structure looks like.

Use 'native' poetry features for 'pyansys-advanced' poetry option?

Description of the feature

When instantiating pyansys-advanced with poetry as a build tool, it still produces the requirements/requirements_*.txt files. My (limited) understanding of poetry is that the native way of doing this would be adding extra dependencies, which can be installed with e.g. poetry install -E docs.

The role of the requirements_*.txt files would then be taken over by the poetry.lock file.

Similarly, the installation instructions refer to manually creating a virtualenv, whereas poetry includes virtualenv management. FMPOV, documenting the use of the "native" poetry commands gives a better user experience.

If there's a specific reason why the native poetry commands don't work well, I'd be very interested to know it.

Tagging @jorgepiloto for comment.

Bug located in README.rst

🔍 Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

🐞 Description of the bug

The hyperlink is invalid https://templates.pyansys.com/
This is on line 48 of Readme.rst

📝 Steps to reproduce

Select the hyperlink.

💻 Which operating system are you using?

Windows

🐍 Which Python version are you using?

3.8

📦 Installed packages

This is a documentation error and not related to Python code.

Switch to official cookiecutter

Cookiecutter has been released, see:
https://pypi.org/project/cookiecutter/2.1.0/

Implement slideshow template

💡 Implement slideshow template
It would be very interesting to have a template for creating slideshows. Main users of this target would be developers who want to:

• Focus on slide content rather in final style, that is using a Markup language.
• Avoid Power Point interaction while still being able to export to this format.
• HTML and PDF export support.
• Have support for LaTeX math, image customization and code snippets.

📝 Implementation
From personal experience during SciPyConf 2022, Marp turned out to be an excellent tool covering all previous requirements.

We could implement our own Ansys theme for this theme, emulating the current one for Power Point presentations.

Merge with Create-Python-Project

We need to implement the following features from https://github.com/pyansys/create-python-project:

• Fully utilize pipx
• Add in fancy *gif (good idea @asbfall) and badges
• Create a common directory to share common files across multiple templates. This will avoid duplication of LICENSE, CONTRIBUTING, etc.
• Add in gRPC, REST, and docker templates. Use common files via a pre-hook
• Expand documentation with directions for adding additional templates.

Finally, we should discuss if we should be limiting these templates to just Python, or expand it into C#, C++, JavaScript, etc.

Use cookiecutter for templating

The man idea is to use cookiecutter as the templating tool. Project structure should be the one defined in pyansys/template repo. An already built cookiecutter template can be found in the ansys/ansys-api-template.

Change domain name from pyansys.com to ansys.com

Now that we have moved it to the @ansys org, we should modify the CNAME. This involves opening a ServiceNow ticket with IT

Implement logger

The architecture of the hooks we use to trim unnecessary files makes it difficult to work out what's wrong when template generation does not go as expected.

Cookiecutter provides a --verbose argument which enables much more logging. We should make sure this can be enabled by our scripts, and we should also make sure it enables logging within our template utilities.

For example I would like to know which files it removes/leaves when executing keep_files(), if I had access to this information I would have noticed the missing comma in my DESIRED_STRUCTURE list

Include coverage dotfile in Python templates

After merging https://github.com/pyansys/pyadditive/pull/1, I saw that the CI logs are measuring the wrong coverage. These are assuming that the tests are the source files, instead of the ones located in the src/ directory.

The following .coveragerc file should be added to the src/ansys/templates/python/common/{{cookiecutter.__project_name_slug}}:

[run]
source =
    ansys/{{cookiecutter.__project_name_slug}}

[report]
show_missing = true

In addition, the tox.ini file should be updated too. See https://github.com/pyansys/pyansys-templates/blob/main/tox.ini#L25

Issues templates no longer available

Due to the change of org, we have lost the issues templates available at PyAnsys. Do we want to keep them for this repo? If that's the case we should create a local copy for this repo..

Pinging @jorgepiloto for discussion. If we decide to do that, I can take care of it, no problem.

Missing metadata in pyansys-advanced setup.py file

The current setup_setuptools.py template file is missing some metadata. In particular, the fields author, maintainer and maintainer-email are missing:

https://github.com/pyansys/ansys-templates/blob/971eba81d301cc522f29b1fe925bd5340b5d5836/src/ansys/templates/python/pyansys_advanced/%7B%7Bcookiecutter.__project_name_slug%7D%7D/setup_setuptools.py#L5-L22

Make ansys-advanced/pyprojec.toml PEP 621 compliant

🐞 Problem

Similar situation as in #46. Duplicated instances of pyproject.toml for the build-system tools flit and poetry.

💡 Solution

Combine those into a single file.

Unify pyansys_advanced/tox_*.ini files

🐞 Problem

The tox_*.ini files in pyansys_advanced/{{cookiecutter.__project_name_slug}} are not so different from each other. They just differ in a couple of lines between them.

💡 Solution

Instead of having three of these files, we can benefit from Jinja syntax to have a single file which renders according to the type of build system tool.

Ask whether vale should be implemented as an optional workflow or within the main CI/CD

📝 Description of the feature

As a follow-up of the PyAnsys meeting, it was recommended to provide Vale as optional such that:

• We should ask the user if they want to implement vale in CI/CD
• Otherwise, it will be set up as an optional workflow

vale should be implemented so that the docs teams can run it, but if users don't want it to be part of their main CI/CD workflow, we should also allow it. This would be the perfect balance since the docs team will be able to run vale whenever they need, and it will not harass the developers in every PR.

💡 Steps for implementing the feature

Depending on the user's answer:

• Provide vale inside the main CI/CD workflow
• Provide vale as a separate, optional workfow

🔗 Useful links and references

Ask @RobPasMue in case of doubts

Include Vale config as part of the docs structure

Description of the feature

Following the discussions with vale, it would be interesting to include it into the ansys-templates project. Please refer to some of the repos which already have it implemented: pyansys/pyansys-tools-report, ansys/api-eigen-example, ansys/api-guidance.

Steps for implementing the feature

Implement config file and styles.
Implement CI if possible.

Useful links and references

No response

Implement new doc-project template

💡 Implement doc-project template

Let us simplify the workflow from our documentation team by providing them with a template. This template should contain the minimum files to set up a Sphinx documentation project.

Simple questions like "Select logo [Ansys, PyAnsys]" or "Enable NavBar icons [Yes, No]" could be implemented.

Add more project urls

💡 Add more project urls
In the pyrpoject.toml file, the [project.urls] section looks like:

ansys-templates/pyproject.toml

Lines 38 to 39 in 6dd7669

	[project.urls]
	Source = "https://github.com/pyansys/pyansys-template"

However, the following links could be added too:

[project.urls]
Homepage = "https://github.com/ansys/ansys-templates/"
Documentation = "templates.pyansys.com/"
Source = "https://github.com/ansys-templates/ansys-templates"
Tracker = "https://github.com/ansys/ansys-templates/issues"

Move tool configuration from .pre-commit-config.yaml to pyproject.toml

When configuring an IDE, it's common to use "format on save" feature that triggers linter each time you save. Unfortunately, in my case, black would format to its default of 88 character per lines, that were clashing with the pre-commit's 100 characters.

If this configuration is moved into pyproject.toml, then both pre-commit and the IDE (or just black called independently) are able to interpret it, solving the issue.

FYI, I've applied this fix in ansys/pypim#6 This fix omits pydocstyle as I'm not very confortable with this tools usage.

Weird error with pipx run command as specified by project documentation

I get the following error when I follow the getting started guide, with the slight modification that I installed pipx into a venv instead of as --user.

Note that it works just fine if I use ansys-templates --help instead of pipx run ansys-templates --help

(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ pipx run ansys-templates --help
⚠️  ansys-templates is already on your PATH and installed at /home/nsharp/.local/bin/ansys-templates. Downloading and running anyway.
Fatal error from pip prevented installation. Full pip output in file:
    /home/nsharp/.local/pipx/logs/cmd_2022-03-21_05.46.44_pip_errors.log

Some possibly relevant errors from pip install:
    ERROR: Could not find a version that satisfies the requirement ansys-templates (from versions: none)
    ERROR: No matching distribution found for ansys-templates
Error installing ansys-templates.
(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ cat /home/nsharp/.local/pipx/logs/cmd_2022-03-21_05.46.44_pip_errors.log
PIP STDOUT
----------

PIP STDERR
----------
ERROR: Could not find a version that satisfies the requirement ansys-templates (from versions: none)
ERROR: No matching distribution found for ansys-templates
(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ pip --version
pip 22.0.4 from /home/nsharp/ver/PyVarTypes/venv/lib/python3.8/site-packages/pip (python 3.8)
(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ pipx --version
1.0.0
(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ python --version
Python 3.8.0
(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ cat /etc/issue
Ubuntu 18.04.6 LTS \n \l

(venv) nsharp@ubuntu:~/ver/PyVarTypes/t$ ansys-templates --help
Usage: ansys-templates [OPTIONS] COMMAND [ARGS]...

  Ansys tool for creating new Ansys projects.

Options:
  --help  Show this message and exit.

Commands:
  list     List all available templates names.
  new      Create a new project from desired template.
  version  Display current version.

Explore the usage of the template via pipx

💡 Feature request

At the moment, users are forced to install cookiecutter to be able to bake their projects. This ships with the following disadvantages as pointed out by @asbfall:

• Users need to know the url of this repository in order to run cookiecutter gh:pyansys/pyansys-template. If at some point this repo URL is changed, users should be aware of it. Otherwise, previous command will fail.
• Users require from installing cookiecutter in a venv. Although not mandatory, this is a good practice. Users might not be familiar with this workflow. This is the reason behind pipx.

🎯 Goal

The main goal of this feature request is to substitute the current workflow:

cookiecutter gh:pyansys/pyansys-template

by:

pipx run pyansys-template

One additional advantage are, for example, is the ability to pass arguments and options. Imagine having multiple templates and users being able to select which one of those to be baked (or even the build-system):

pipx run pyansys-template --template pylib --build-system poetry
pipx run pyansys-template --template gRCP