You can define a C extension just fine with enscons’ SConstruct, no setup.py required. Maybe pymsbuild does it too. Even the distutils 2 attempt from a decade ago put extensions in setup.cfg. setup.py does no magic it just knows a few compiler flags.
C extensions should work fine with .pth or import hooks same as .py
The truest Python old-timers still set PYTHONPATH but the package would not show up in pip list which sometimes matters.
I guess we’re having a disgreement on symlink functionality. You say one can do via inserting a startup code into the interpreter that performs the symlink operation. I don’t think this is a smart approach we should publicize. In essence the backend is creating files into the target interpreter the frontend is not aware. The frontend will not be able to uninstall these because it doesn’t know they exist. Or the backend needs to generate pre-emptively entries into the RECORDS that are not there, but can be there. Not sure if the RECORDS file within wheels supports this, or if frontend would not choke on it either at install or uninstall time.
In theory, it can. However, feels like there’s an easier solution by defining an interface where the frontend can explicitly create the symlink, and not mandate the need of a meta folder to achieve this functionality.
I don’t see any mention on this topic on PEP 517 either. So I’d like to ask for clarifications on the question here.
The existing hooks in PEP 517 do not pass in any target interpreter specific information in PEP 517. PEP 660 for some reason does pass in the scheme argument that seems to tie it to a specific interpreter and nothing else. So while you can take a universal wheel and reuse it across multiple interpreters, the defined interface seems to discourage this. The PEP should be clear if it does not plan to offer similar guarantees PEP 517 does.
I don’t think we should take the stance that reorganize your project or its configuration to make it editable friendly. I believe desiging a system that can solve the problem without this would be prefered.
I’m not sure how this is relevant at all here. I’m by no means a setuptools maintainers. And both the virtual wheels and the PEP-660 gets you there independent of what alternative backend you want to go with.
I’ve been mildly interested in adding symlink support to wheel. What if we added a permissions column to RECORD. If it contains a lowercase l, interpret the content of that file as a symlink. Optionally set the standard zip file symlink attribute.
Regarding headers and data files, PEP 660 puts them explicitly out of scope in the Terminology and goals section, by saying we focus on making python files editable. If supporting editable headers and data files become a key criteria for adopting an editable PEP, then it’s symlinks or , I suppose ?
Regarding scripts, well, I’m personally fine to say they can’t be editable and recommend project authors to migrate to console scripts if they want that. Editable scripts does not sound like a strong differentiator, especially if the only known way to implement that is symlinks.
I disagree. Sure it’s useful but I’d say not complete without it. In a world where PEP-660 gets accepted and symlink PEP rejected, we’d be worse off than a competing proposal that would add support for symlinks. So if we go down this lane I’d like the two PEPs to be accepted/rejected together.
In mind editable installs are about Python packages, not python files. So in this sense I guess the two PEPs currently have different goals. Similar to how PEP 517 covers packaging for editable packages, and not pure Python projects this pep should also cover packages not files.
I don’t think symlinks would work here, but proxy scripts generated would, so I see no reason why not go down that path.
Yes, I hope that we can decide that this implemented PEP is fine as is and without symlinks, making it easier to provide a feature that many people like. The “strictest possible simulation of an install without actually copying the files” idea is different, could we call it ‘preflight’ mode?
Windows 10 from the last few years does support symlinks, you should try to use it helps a lot efficiency/performance in virtualenv for example
I think based on discussion above we can conclude that we can’t agree and we’ll have to let the packaging BDFL or the steering council pick a solution. Many people do want editable installations, but both PEP provide this functionality so there’s no this reasoning can’t be used by either option.