poetry and capital letter in package names

[pmav99]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Linux D01RI1900987 4.15.0-66-generic Detect pyproject.toml changes and automatically run poetry install if needed #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

• Poetry version: Poetry version 1.0.0b3

Issue

poetry does not seem to correctly handle packages with capital letters

create a new package

$ poetry new myPackage
/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/subprocess32.py:149: RuntimeWarning: The _posixsubprocess module is not being used. Child process reliability may suffer if your program uses threads.
  "program uses threads.", RuntimeWarning)
Created package myPackage in myPackage

$ ls
myPackage

Inspect pyproject.

It correctly contains the capitalized name

$ cat myPackage/pyproject.toml
[tool.poetry]
name = "myPackage"
version = "0.1.0"
description = ""
authors = ["Panos Mavrogiorgos <pmav99@gmail.com>"]

[tool.poetry.dependencies]
python = "^2.7"

[tool.poetry.dev-dependencies]
pytest = "^4.6"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Nevertheless, the created package is in lowercase...

$ ls myPackage
mypackage  tests  README.rst  pyproject.toml

Try to build a wheel - everything seems fine:

$  poetry build
/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/subprocess32.py:149: RuntimeWarning: The _posixsubprocess module is not being used. Child process reliability may suffer if your program uses threads.
  "program uses threads.", RuntimeWarning)
Building myPackage (0.1.0)
 - Building sdist
 - Built myPackage-0.1.0.tar.gz

 - Building wheel
 - Built myPackage-0.1.0-py2.py3-none-any.whl

Use Capital letters

But if we rename the package to myPackage then there is an exception.

$ mv mypackage myPackage
$ ls
myPackage  tests  README.rst  pyproject.toml
$ poetry build -vvv
/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/subprocess32.py:149: RuntimeWarning: The _posixsubprocess module is not being used. Child process reliability may suffer if your program uses threads.
  "program uses threads.", RuntimeWarning)
Using virtualenv: /home/pmav99/.cache/pypoetry/virtualenvs/mypackage--uDnKC_a-py2.7
Building myPackage (0.1.0)

[ModuleOrPackageNotFound]
No file/folder found for package mypackage

Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/pmav99/.poetry/bin/poetry", line 14, in <module>
    main()
  File "/home/pmav99/.poetry/lib/poetry/console/__init__.py", line 5, in main
    return Application().run()
  File "/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/clikit/console_application.py", line 139, in run
    trace.render(io, simple=isinstance(e, CliKitException))
  File "/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/clikit/ui/components/exception_trace.py", line 57, in render
    self._render_traceback(io, tb)
  File "/home/pmav99/.poetry/lib/poetry/_vendor/py2.7/clikit/ui/components/exception_trace.py", line 67, in _render_traceback
    io.write_line("".join(traceback.format_list(frames)))
  File "/usr/lib/python2.7/traceback.py", line 39, in format_list
    item = '  File "%s", line %d, in %s\n' % (filename,lineno,name)
TypeError: %d format: a number is required, not str

Could this be something similar to #1303 - #1305?

[finswimmer]

Hello,

poetry is forced to rename package folder to lower case and replaces . and - by _. This convention is defined by PEP8.

It looks a little bit counter intuitive that the name in pyproject.toml stayes the same like the project folder and not the renamed package folder.

I could change this behavior, in that way, that the name value gets also renamed. But I'm not sure if this is intended? @sdispater

[pmav99]

I would argue that PEP 8 is a style guide. A widely accepted one, but still, nothing more than a suggestion. There are projects that use capital letters in their letters and this could prevent them from adopting poetry.

That being said, even if there is some reason that poetry can't support mixed cases (filesystems that ignore cases?), the following output is wrong:

$ poetry new myPackage
Created package myPackage in myPackage

More specifically, this part:

Created package myPackage in myPackage

[finswimmer]

Hello again,

you can use camel case package names. But then you have to define it in the pyproject.toml like this:

packages = [
    {include = "myPackage"}
]

See also here.

And yes, the output message is incorrect.

[pmav99]

Great, thank you @finswimmer.

[finswimmer]

Do you think we can close this issue, if my fix about showing the message correct is merged?

[kierun]

I got the same problem in 1.0.0. @finswimmer fix worked for me. The message I got was a stack trace which was less than helpful. Still, the solution works so thank you.

[mdaeron]

I would argue that PEP 8 is a style guide. A widely accepted one, but still, nothing more than a suggestion. There are projects that use capital letters in their letters and this could prevent them from adopting poetry.

I would like to ask about reopening this issue to carefully consider the case for supporting capitalized package names. I am the author of the D47crunch package used by geochemists, and I am trying to switch to poetry. There are two strong reasons I will not change the package name at this point:

1. Asking users to switch to a new package is going to be a mess;
2. Semantically, there is a critical difference between d47 and D47 in geochemistry, so in this case the uppercase D is part of the message.

I am a big fan of style guidelines, both for code and for writing in general, but I also believe it's important to know how/when to deviate from the default style. It would be great if there was a simple way to force preservation of the original capitalization, perhaps with a strongly worded warning pointing to PEP 8. If this is simply not technically possible and/or unacceptable on philosophical grounds, authors of existing capitalized packages will have to do without poetry, which would suck.

Thanks for hearing me out and for the great work you've done so far.

[kierun]

@mdaeron My use case at the time was with acronyms for machines so PIF (Pipe Installation Frame) was not equal to pif…

As I said, @finswimmer fix worked for me:

packages = [
    {include = "PIF"}
]

But it is more verbose.

[mdaeron]

Oh great, I didn't realize that fix applied to the main package name and thought this was about dependencies. Thanks again!

[mdaeron]

I just tested this for an upcoming package D47calib:

1. I first created and published the 0.0.1 package with twine, which resulted on a PyPI project named D47calib.
2. I then made some minor edit, bumped version to 0.0.2, and published it with flit, which preserved the PyPI project name D47calib.
3. I finally made some minor edit, bumped version to 0.0.3, re-generated pyproject.toml with poetry, with packages = [{include = "D47calib"}] as suggested above, and published with poetry. This, surprisingly, changed the PyPI project name to d47calib (with lowercase d). I can still do pip install D47calib and import D47calib after that, so this seems to be a cosmetic issue.

Nevertheless, is there a way to avoid this renaming?

[kierun]

@mdaeron I am afraid I will have to leave it to more knowledgeable people. I moved on from those projects and thus no longer have a need for capitalisation of packages. However, I do think (for what my opinion is worth) that poetry should support it despite PEP8. There are cases where it is essential to have capitalisation.

[dsalaj]

I stumbled upon this issue recently during migration of a package from other dependency manager to poetry (the package name contained caps PackageName). After finding all the workarounds and this thread, my main concern is the lack of proper warning message in the output of poetry install.
This wasted a lot of time for me and I would like to suggest at least including an informative warning when the root package is not installed. Something like:
Warning: The current project will not be installed due to non-conventional naming. To install it please include the package explicitely, see https://python-poetry.org/docs/pyproject/#packages

[jduprey]

For clarity, is it "poetry's" position that it is going to be very opinionated over package names and not allow uppercase characters? Further that it can be overridden if a project insists, but if that override were to work then it should also publish with the proper case, which seems to not be the case?

Either way, it seems like there is a bug - either 1. poetry is insisting upon lower case and that was not intended or 2. package name override isn't honored when published to PyPi, .. or maybe BOTH?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.