I mean is this golang or Python? In Python, you raise notimplementederror. On Aug 24, 2017 8:17 AM, "Thomas Kluyver" <thomas@kluyver.me.uk> wrote:
Nathaniel seems to be busy with other things at the moment, so I hope he won't mind me passing on this list of things he'd like to resolve with the draft PEP. I'll quote his comments and put my responses inline.
- needs some sort of NotImplemented(Error) handling specified
We've gone round return-value vs exception a few times, but I don't think that debate is particularly heated, so it probably just needs someone to say "this is what we're doing". I can be that someone if needs be. But does anyone feel strongly about it?
- The out-of-tree build example (that makes an sdist and then builds it) seems like exactly the kind of implementation that Donald says he doesn't want to see? OTOH I think Nick said he wants to see a more elaborated specification of out-of-tree build strategies with this specifically as one of them. - Nick has suggested that the to-be-defined NotImplemented(Error) handling can be used by build_wheel to indicate that it can't do out-of-tree builds, so maybe the frontend should try an in-tree build instead. I don't know how to convert this into a real spec, though -- like in general, if I'm a frontend and I call `hook(*args, **kwargs)` and it says "can't do that", then how do I know what the problem is and what I should try instead? - What happens if prepare_build_metadata returns NotImplemented / raises NotImplementedError? - I don't understand how out-of-tree builds and prepare_build_metadata are supposed to interact. - Also, AFAICT the out-of-tree build feature has no motivation anymore. The only mentioned use case is to support incremental build features in automatic build pipelines like Travis, but there are a number of these build pipelines, and lots of existing build systems that support out-of-tree builds, and AFAICT no-one actually uses them together like this. (I think it's because most build systems' out-of-tree build features are designed on the assumption that there's a human running the show who will deal with any edge cases.)
I believe the out-of-tree build option Nathaniel is referring to is the build_directory parameter to build_wheel(). His proposed APIs remove that parameter, and elsewhere in his email he describes that no-one seems to want it: everyone thinks someone else wants it.
By my understanding, the reasons for including the build_directory parameter are:
1. Without an explicit build directory, the developers of pip are concerned that build backends will modify the source tree and cause issues which users report as bugs to pip. 2. A frontend-controlled build directory could be used for caching intermediate build artifacts. This was a secondary argument after we had the idea, and we've never really fleshed out how we expect it to work. There's also a concern that if the first round of frontends always use an empty tempdir, backends will end up relying on that. I think this second argument is a weak one unless we spend the time to figure out the details.
Do other people see the situation in a similar way? How might we move forwards on this?
- needs some sort of conclusion to the srcdir-on-sys.path issue.
While Nathaniel is in the minority regarding srcdir-on-sys.path, he argues that most of us are assuming a default position without really thinking through it, which is certainly true of me. I don't feel strongly about this topic, but I do want to come to a conclusion. As Nathaniel does feel strongly about it, does anyone object to either:
A. Leaving the source dir off sys.path when loading the hooks, and making a special backend which exposes hooks from the CWD. B. Adding another key in the TOML file to control whether hooks can be loaded from the source dir.
I can live with either, but I prefer A, because it means fewer options to describe in the spec.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig