Add fork using poetry 1.0 to list of templates

[croesnick]

Starting out with the goal to move code under a dedicated src directory, I ended moving a few more things around, including the introduction of Poetry 1.0 for package management. Hope you like it. :)

[Zethson]

Very interesting. Why did you move everything into a src folder?
Does this adhere to best practices?

[Zethson]

I personally also think that the top level make file is not a bad idea.

[Zethson]

Furthermore, after running
poetry install

I cannot
ls
anymore?

Traceback (most recent call last):
  File "/home/zeth/anaconda3/envs/cookietemple/bin/test", line 11, in <module>
    load_entry_point('test', 'console_scripts', 'test')()
  File "/home/zeth/anaconda3/envs/cookietemple/lib/python3.8/site-packages/pkg_resources/__init__.py", line 489, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/zeth/anaconda3/envs/cookietemple/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2852, in load_entry_point
    return ep.load()
  File "/home/zeth/anaconda3/envs/cookietemple/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2443, in load
    return self.resolve()
  File "/home/zeth/anaconda3/envs/cookietemple/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'test.cli'

My package also doesn't seem to be installed correctly, since nothing happens when I run 'test'?

[veit]

Very interesting. Why did you move everything into a src folder?
Does this adhere to best practices?

Some considerations about the src folder are described by @hynek in Testing & Packaging.

[Zethson]

Thank you for the link. I'm still split and do not know which version I prefer :)

[croesnick]

Thanks @veit for sharing the link. This is indeed the same resource I took the idea to move everything beneath a src folder from.

Regarding your issue, @Zethson, creating a package named test: Just by the package's name, I assume at least two different effects could pop up here.

1. Your module might shadow bash built-in test command which could cause lots of funny side effects.
2. Your module, when run via python -m test.cli, might interfere with Python's built-in package test. This at least seems very plausible when running python -m test -h.

Gist: Could you try creating a differently named package (excluding the names test and tests)? 😊