> On Jun 1, 2017, at 2:12 PM, C Anthony Risinger <c...@anthonyrisinger.com> > wrote: > > Because the build itself can output additional source files, that may be > desirable to include in an sdist later, I honestly don't think you can pass > through a "proper" sdist before a wheel. I think you can 99% of the time do > that, but some builds using Cython and friends could actually have a custom > initial build that generates standard .h/.c/.py, and even outputs an > alternative p > yproject.toml that *no longer needs* a custom build backend. Or just straight > deletes it from SOURCE-RECORD once the custom build is done, because some > artifacts are enough to rebuild a wheel next time. It seems to me the only > possibly correct order is: > > 1. VCS checkout > 2. partial sdist, but still likely an sdist, no promises! > 3. wheel > 4. proper sdist from generated SOURCE-RECORD, or updated static > SOURCE-RECORD, or just original source tree + DIST-INFO > > I don't see a way to get a 100% valid sdist without first building the > project and effectively asking the build backend (via its SOURCE-RECORD, if > any) "Well golly, you did a build! What, *from both the source tree and build > artifacts*, is important for wrapping up into a redistributable?" > > Maybe I'm overlooking something yuge (I've tried to follow this discussion, > and have sort of checked out of python lately, but I'm fairly well-versed in > packing lore and code), but in general I think we really are making sdists > way way... way scarier than need be. They're pretty much whatever the build > tells you is important for redistribution, at the end, with as much static > meta > data as possible, to the point of possibly obviating their need for > pyproject.toml in the first place... maybe this aspect is what is hanging > everyone up? A redistibutable source does not need to be as flexible as the > original VCS input. An sdist is pinned to a specific version of a project, > whereas VCS represents all possible versions (albeit only one is checkout > out), and sdists > *are not* wheels! The same expectations need not apply. Two sdists of the > same version might not be identical; one might request the custom build > backed via pyproject.toml, and the other might have already done some of the > steps for whatever reason. Authors must decide which is more appropriate for > sharing.
Do any projects build a copy of the library and use that for influencing what gets copied into the sdist today? As far as I am aware there is not any that do that. I think the standard thing to do in Cython is to produce the .c files as part of the sdist process, which is perfectly fine to do. With the newer PEPs it doesn’t _need_ to do that, since you can depend on Cython in your build steps and just ship the pyx files (although you’re still free to compute the .c files AOT and include them in the sdist). — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
