collaboration with conda-eda

[proppy]

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?

[ryanvolz]

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.

[proppy]

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.

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.

Is there anything in particular compatibility-wise that I should be aware of?

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).

I'd happily include some packages if it makes sense for radio users

Do you have a list of such packages, I'd happily file issues to track the ask.

the easiest step could be adding another default channel so that installation of conda-eda packages is a single command.

If we manage to get parity on conda-forge (as discussed earlier), we should be able to use the current radiaconda setup as it.

[ryanvolz]

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.

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!

Do you have a list of such packages, I'd happily file issues to track the ask.

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.

[ei8fdb]

Do you have a list of such packages, I'd happily file issues to track the ask.

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.

[ryanvolz]

Do you have a list of such packages, I'd happily file issues to track the ask.

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.