Hello, On Mon, 27 Oct 2014 15:49:21 +0000 Paul Moore wrote:

On 27 October 2014 15:15, Paul Sokolovsky wrote:

...

...

For a source distribution, you could play clever games in setup.py to put the right file in place, with the right name. But that's messy and it means that if you distribute wheels (not that there's much point in doing so) you need separate wheels for 2.6-, 2.7 and 3.3+.

Ok, so are there guidelines, best practices or at least example(s) how to do that? I pretty much would like to avoid inventing my own "clever games" to achieve that.

Personally, my guideline would be "don't do that". We're trying to move away from having complex code in setup.py, to a more nearly declarative solution.

It's great to hear there's move in declarative direction. And all the above is actually the reason I wrote "I don't want to invent my own way to do it". What I'd like to have is such declarative/data-driven way to select which files to install, based on some predefined (alternatively, user-defined) criteria. As current setuptools work in imperative manner, I essentially asked 1) how to code up conditional file installation with setuptools; 2) how to set my "custom" metadata/structure in such a way that it would be compatible with current community direction/best practices towards future fully declarative solution. Thanks for the code in the other message, it gives good hints for question 1. I still could use some guidelines on question 2 (or alternatively, as you write below, maybe you/other distutil-sig developers could use it when designing future solution). Let me give one example of possible many how these could be structured: So, in my src dir, I could have: os.py PLATFORM-macosx/os.py PLATFORM-pyboard/os.py Installer could see a special directory names starting with a set of predefined property names (uppercased to avoid easy clashing with user dirs). In this case, PLATFORM means sys.platform. If substring after hyphen matches its value, corresponding file is installed, otherwise file in the main dir is used as a fallback. So, would the schedule above be along the lines of your thinking how that should be done, or you're immediately see bunch of issues with it (I sure do - it's easy on packager's side, by not so easy on tool's side to figure what packager wanted, so more disambiguation surely would be required)? Then, would you have suggestion for better structure? If the intent of the above is still not clear enough, let me put it this way: with MicroPython, we won't be able to use pip in self-hosting mode (for various reasons), so we'd need to develop own lightweight package manager. It for sure would use declarative approach. So, we're looking for what kind of metadata and approach we should take to stay with general Python community's outlook of this? (And we want our packages to be still installable with current and future pip of course.) Thanks!

The above approach pretty much directly goes against that. I posted code later in the same thread, but I still don't think people should be doing it.

I see the issue you and Ethan have, though. It should be considered in the context of Metadata 2.0 and things like that, so we make sure the use case is covered.

Paul

-- Best regards, Paul mailto:pmiscml@gmail.com