Poetry: "private" packages

[ojii]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.

I think it would be useful if in my pyproject.toml I could specify that a package is private. This could be done via [tool.poetry] private = true. What this would do is disallow poetry publish without an explicit repository, to prevent accidental publishing to pypi.org. It could also make the license key optional. There may be other ways private projects should behave differently, but for now I'm mostly interested in the publish prevention.

If this is a feature that is desirable, I'd be happy to implement it. EDIT: See https://github.com/ojii/poetry/tree/private-packages for a simple implementation.

[golyalpha]

License is optional, afaik. Even the poetry new command doesn't generate it/ask for it.
That being said, custom package repository should be set in the pyproject.toml for private project, and if it isn't, it's unlikely that the private option would be set either.

[ojii]

The main goal is to prevent accidental publishing to public pypi by requiring to explicitly chose a repository when using the publish command.

[golyalpha]

Maybe let users set a default publish repository in the project config instead?

[ojii]

That would be an alternative. For what it's worth, the JS ecosystem has a private flag for their package metadata (which is where I got the idea from).

[golyalpha]

Well, maybe then add it still, if just to make it more similar to npm/yarn, but I still think it's more useful to set a publish repository, instead of a flag that will force you to type it out every time you want to publish.

About the license tag, if you have a proprietary, "All rights reserved" package, then people should use UNLICENSED. (Not to be confused with The Unilicense, which is quite the opposite of ARR)

[s0undt3ch]

I just started reading through poetry's docs and issue tracker so I don't really know if it prevents you from setting invalid package classifiers.
PyPi.org prevents the upload of packages with unexisting classifiers.
Also, please consider this a hack that currently works but might stop working.
Add, for example, Private :: Do Not Upload as a classifier.

[alairock]

Bump. This feature would be really great. Thanks!

[golyalpha]

@s0undt3ch As you yourself said, that is a hack, and therefore, should only be used in case it's impossible to implement said feature properly.

[s0undt3ch]

No longer a hack

Python Package Index (@pypi)
This excellent tip from @oscar_mcm is now reliably implemented. Classifiers beginning with “Private ::” are now disallowed from even existing in PyPI’s database. https://t.co/NKtdUDIYfR
(https://twitter.com/pypi/status/1097241506304454656?s=09)

[dnutels]

I am confused as to what a resolution here is? poetry uses pyproject.toml, as it should, while the suggestion in the links above is to use setup.py.

Perhaps a line or two in the docs, if this is indeed a solution?

[golyalpha]

@dnutels
Here's the doc talking about classifiers in pyproject.toml: https://poetry.eustace.io/docs/pyproject/#classifiers
Since classifiers itself are not a mechanism related directly to Poetry, but rather packaging and Python in general, I don't see a reason that particular thing should be in Poetry's docs.
PEP talking about classifiers: https://www.python.org/dev/peps/pep-0301/#distutils-trove-classification

[ojii]

I still think private = true would be a lot easier to understand and remember. With the classifier I'll have to look it up every time. But I guess it works...

[golyalpha]

@ojii That may be true, but then there's the fact that you could be able to specify a default publish repository in the pyproject.toml, and be done with it, without using classifiers, or having to implement and use private = true.