Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
When to package software which is already in the default conda channel
See original GitHub issue(@JanSchulz brought this up in https://github.com/conda-forge/conda-forge.github.io/issues/16#issuecomment-182430891)
I Agreed with @JanSchulz that we should avoid as much as possible to add packages in conda-forge that are available in the default channel.
However, we already have a few redundant packages (pyproj, shapely, geos, and more to come soon). The reason for th1 redundancy is that those packages are partially broken in the default channel.
(And we could not find a proper channel of communication to send the recipe patch back to them.)
Maybe, when fixing a default channel package we should allow the package addition here as long as there is a plan to send that fix back to the default channel, and to remove the package from conda-forge once that happens.
Issue Analytics
- State:
- Created 8 years ago
- Comments:85 (71 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
centos:fedora:RHEL :: conda-forge:anaconda:anaconda-enterprise
I am closing this issue as I believe we already know what to do when submitting a package that is already in the default channel. Just write the reason why are you submitting the package to conda-forge in the PR (e.g.: new patch to solve X, missing dependencies, latest version, etc).