On 9 October 2014 16:02, holger krekel
Alternatively, and just as good from my POV, would be for the plugin to add the wheels to a local index of my choosing. That would preserve /root/pypi as a PyPI mirror, but I could add my wheel index as an extra index URL, to get the wheels that way.
The second option seems to fit better how things work internally currently. So something like:
1. setup X/pypi_with_wheels, inherit from root/pypi 2. implement a wheel builder plugin that implements a new devpi_server_on_pypi_upload(link) hook which triggers an async script that does download, convert, upload to root/pypi_with_wheels.
should be implementable without too much effort.
Cool. When you say "implements a new hook", can plugins implement hooks? If that's what you mean, I'll give it a go and see if I can write something (expect requests for help, I've not looked into writing plugins yet!) If you mean that devpi would need to implement a new hook internally first, I'm not sure I know enough to be able to do that...
Somehow it'd be nice, i guess, if we could make things more real-time, i.e. you would always see wheel links on the simple page to begin with. There would be wheels made out of sdists, exe, whatnot and they would be created dynamically when actually accessed. This would probably make most sense for per-machine devpi deployments. Implementing this requires probably some more effort.
(Near) real-time would be best for me. My ideal would be (for example) to have "pip install lxml" install a wheel built from the exe that's available on PyPI. If the wheel convert happens asynchronously, that would mean the first install would fail, but if I repeated the install it would work. Paul