Is it possible for a package to provide both an application and a library at the same time in python?

Yep, fixed in 473c470. That will require a new function toPythonApplication which basically does the opposite of the current toPythonModule.

Are there any real pure-Python applications that cannot be imported as a library?

If they don't put their modules in site-packages, then it gets hard to import them. So, if they don't use setuptools/distutils/flit, that typically is the case.

However, I don't think it is important whether it is technically possible, but whether it is meant to. I would argue that upstream application developers typically use setuptools to make it easier to distribute and that it is therefore just an implementation detail.

I agree with your examples where there is a technical distinction. But what is gained by relying on intent when there is no technical hard distinction? If it is built just like a Python library, and it can be used as a Python library, and it can be generated by pypi2nix and copied into the package set with a minimal cleanup — shouldn't it be duck-typed to a «Python package» and then maybe also aliased to the top-level namespace?

But what is gained by relying on intent when there is no technical hard distinction?

No practical gain. But as the language is an implementation detail it could be changed, whereas its purpose and thus its location in the tree would remain the same. Although, as you write, a pragmatic solution could be:

and then maybe also aliased to the top-level namespace?

In practice, though, there is actually another reason to have them separate: the additional constraints (pinning) typically imposed by applications (NixOS/nixpkgs#34775).

In my experience, libraries can also have interesting version constraints.

I would call a complete rewrite, same or different language, a new package by the same team. Also, of packages I use, Mozilla Marionette (which is a Python package pythonPackages.marionette_driver with no executables — so a library) still supports only Python2 and I wouldn't be surprised if it gets rewritten in Rust instead of updating to Python3.

It seems like a good idea given the current state of tooling. Hopefully we'll have something better than pypi2nix, maybe something more interactive, to build larger snapshots of packages working together.

I would like pypi2nix to eventually be able to support cascading of package sets (that are defined in Nix). Basically, have a main package set, and then secondary sets that build upon and extend the first one, without repeating its values. That would be useful for our applications.

On the other hand, https://manual.calibre-ebook.com/function_mode.html#the-power-of-function-mode-using-a-spelling-dictionary-to-fix-mis-hyphenated-words gives a snippet of code with

from calibre import replace_entities
from calibre import prepare_string_for_xml

Does this make Calibre both application and library?

Good point. So, as I explained in my other comment, technically it is possible. And, in this case it seems it is supported upstream.

I think if there is demand we may consider it as both application and library. Otherwise, leave it as an application.

Maybe pick an example that doesn't use setuptools then?

What if there are no upstream updates and the package actually works well without them anyway?

If it works fine and causes no additional maintenance then they likely would not be removed. But if the expression needs to be fixed because of say changes in dependencies then it will require maintenance.

I surely agree with that. Maybe put the emphasis on this effort? «Packages that have no maintainer may be removed or marked as broken as soon as they require any additional maintenance effort, or there are any indications of dangerous bugs or vulnerabilities.»

Do we actually want to list all the libraries that also happen to provide useful tools in the manual? We don't explicitly mention that openssl is both a tool and a library, after all.

I need better wording for that sentence. Basically, what I would like to say is that there shall be a function toPythonApplication that is documented in the Nixpkgs manual that is to be used for the top-level attribute.

E.g.

calibre = with python.pkgs; toPythonApplication calibre;

What this function will actually do? Create .desktop entries? What about pure-CLI tools?

And what you meant is «There shall be a function to perform additional post-installation steps specific to applications written in Python. This function shall be documented in the Nixpkgs manual.»?

Thanks. I've rewritten that section. Basically, it is important to distinguish applications from libraries because, when a library as part of a development environment needs to call an application, we don't want the dependencies of the application to be added to the Python environment. Or if one application written in Python calls another written in Python.

As this is an implementation detail (the use of propagatedBuildInputs) I on purpose remain vague in this description.

I think that the need for propagation of dependencies is unlikely to change in Python2 or Python3, so even if it is an implementation detail, it could be mentioned somewhere, both in the manual (eventually) and in the RFC.

Actually, there is the requiredPythonModules function in python-packages.nix which is also already used by python.buildEnv and could also be used in buildPython*. That could drop the need for propagatedBuildInputs although it likely increases the evaluation time.