Overview
Request 1169683 accepted
- update to 1.4.1
- Switch to wheel to avoid npm attempting to rebuild resources.
This doesn't work without a network and needs brittle workarounds that can change between releases.
- Update dependencies
This version restores the multibuild
- Created by TheBlackCat
- In state accepted
-
Package maintainer:
badshah400
- Supersedes 1169584
Thanks for the sr, but what is missing? https://build.opensuse.org/package/show/home:badshah400:branches:devel:languages:python:numeric/python-panel seems to build and test ok.
If you look at that merge request the build was looping over a file that no longer exists. That had to be changed. (it is not looping over a single file which is another issue)
Using the wheel is going to be simpler and more robust going forward. No need to manually edit specific files to avoid npm trying to rebuild. This approach was able to completely drop that big chunk of workarounds, workarounds that need to be repeatedly modified to deal with non-user-facing changes in the code.
As long as it is not too convoluted to build from source, I think we should prefer that over the use of pre-built wheels. The latter should be a last resort, only if we desperately need a package that simply too difficult to build from source. Frankly, I would actually consider dropping a package if build-from-source becomes nearly impossible.
This is just my opinion. I will accept it, without welcoming it, if prj maintainers decide to okay packages using pre-built wheels in cases like these.
Still, it was, in this case, rather straightforward to get the package building from source in my branch project, as I mentioned previously.
Agreed, although in this case we are using prebundled javascript files in both cases. Whether form the pure wheel or from the sdist is a matter of taste.
Generally that makes sense. But for jupyter-related packages that need to work with npm or yarn during proper builds, wheels are generally more efficient A big chunk of the jupyter-related packages are built from wheels for this reason.
Your branch was already using the same pre-built javascript extension that the wheel uses, so it isn't like it was doing a rebuild from source to begin with. And there isn't any compiled C code. So the wheel is basically the same thing with some unnecessary stuff cut out.
Why disable the multibuild? Best to avoid dependency cycles wherever possible
Having the test in a separate flavour ensures a rebuild of any pkgs from the long list of dependencies used only for testing do not cause the python-panel package build itself (and panel dependencies) to be stalled waiting for them. I think we should continue to maintain the multibuild flavour here for this reason.
Request History
TheBlackCat created request
- update to 1.4.1
- Switch to wheel to avoid npm attempting to rebuild resources.
This doesn't work without a network and needs brittle workarounds that can change between releases.
- Update dependencies
This version restores the multibuild
TheBlackCat accepted request
OK with me. Many thanks