-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
collaboration with conda-eda #39
Comments
It sounds like it makes a lot of sense to work toward compatibility. Most of the packages bundled here are in conda-forge, and the ones that aren't are built with conda-forge-style feedstocks and would be in conda-forge proper if they only had a tagged release. So to the extent that conda-eda plays well with conda-forge, it will play well with the radioconda packages. Is there anything in particular compatibility-wise that I should be aware of? I'd happily include some packages if it makes sense for radio users (probably becoming more relevant in the future if GNU Radio develops ways to use FPGAs directly and not just as a black box part of a software-defined radio), and the easiest step could be adding another default channel so that installation of conda-eda packages is a single command. |
We currently have loose plans to maintain both conda-eda and conda-forge with slightly different requirement, see hdl/conda-eda#193 (comment), I'd be curious to get your take on this given the work you did on radioconda.
Since we don't use the same build environment as conda-forge for most of the packages, it's likely that the default solver won't be happy about common dependencies (libc, python, other native libraries).
Do you have a list of such packages, I'd happily file issues to track the ask.
If we manage to get parity on conda-forge (as discussed earlier), we should be able to use the current radiaconda setup as it. |
That sounds reasonable, at least without me fully understanding the requirements that make the minimal conda-eda packages preferable to the conda-forge versions. I'd imagine that since the primary use of the radioconda packages is interactive and for end users, they would be best used with the conda-forge versions of your packages anyway. In that case, basing them on conda-forge is perfect!
Oh, I really have no idea! I could see users wanting the convenience of being able to install any of them alongside radioconda packages, but I'm not aware of any situation that would strictly require it (i.e. separate conda environments would be OK, losing out only on convenience). Maybe that changes in the future if GNU Radio develops direct FPGA integration. |
Could I offer assistance in finding this out? I understand the original question. However I'm not familiar with FPGA and ASIC tools in terms of GR usage. If someone was willing to give me some help in understanding the detail, I'd be happy to do some research with GR users. |
I think @dkozel knows more about this space, so I'll invite him to chime in. |
We are packaging FPGA and ASIC tools in https://github.com/hdl/conda-eda and@mithro suggested that gnuradio uses FPGAs heavily.
Would it make sense for us to collaborate on packaging best-practices to make sure conda-eda and radioconda packages play well together?
The text was updated successfully, but these errors were encountered: