Hi,
On 6/4/24 8:04 AM, Stefan Monov wrote:
> Forgot to say that I'd be happy to just edit the python code (in its
> installation dir) "in-place", but that carries the risk that conda may
> overwrite all my changes when it updates that package.
Yes, that is what would happen. But it can still be useful to do exactly
this just to test a change quickly. The path to the installed Python
package that you would be looking for is
<RADIOCONDA_INSTALL_DIR>/Lib/site-packages/gnuradio
(on Linux/macOS this would be
<RADIOCONDA_INSTALL_DIR>/lib/python3.11/site-packages/gnuradio)
>
> On Tue, Jun 4, 2024 at 2:59 PM Stefan Monov <logixoul@gmail.com
> <mailto:logixoul@gmail.com>> wrote:
>
> Hi all! Several questions. I'm on Windows and using radioconda.
>
> 1. How do I check if a module is written fully in python (rather
> than C++ or both)?
I think the easiest way might be to go to the Python installation
directory I pointed to above and start poking around in the module that
you are interested in. You will quickly find whether or not what you are
looking for is in a .py file or if it gets imported from a compiled module.
> 2. If I find out that it's written in python, how do I fork it
> (for my personal use)? >
>
> I could do the following:
>
> 1. find the relevant github repo on google
> 2. check if there are any *.cc/*.cpp files in it (to answer
> question 1)
> 3. clone/download the repo
> 4. look for all places in it that mention its name and change
> all of them to my custom module name
> 5. make my changes in the python code
> 6. somehow tell GRC where to find my forked version
>
>
> But this has some problems:
>
> - it's a bit of a hassle, and not very easy for less
> computer-savvy people (like my friend for whom I'm researching
> this. He knows Python but is still not a computer whiz)
> - If there are *.cc files but only for QA/unittesting, I'm not
> sure if I need to compile those.
>
>
> I'm hoping to maybe simply copy&paste the python code (from the
> installed conda package) into some custom dir of my choice, and
> point GRC to that dir. But I'm not sure that'd work. And I'm not
> sure how to do make GRC find my custom dir, or whether I need to put
> YML files in that dir.
>
> I've found tutorials on creating my custom module from scratch with
> gr_modtool, but forking is a different usecase.
>
> Any pointers appreciated :)
>
Aside from the hacky way of modifying the installed code in place, I
don't think there is a more elegant solution than properly forking it as
you describe (and that could include creating a new module with
gr_modtool and copying in code you want to reuse). At that point you are
a developer, and you would have to handle all the normal developer
things like knowing how to build/install your modified package. You
could probably force GRC and Python to find a custom directory, but
really the build system is set up to make that easier precisely because
it is a hassle to do manually.
It sounds like you are prepared to handle the developer side, but you
would want to distribute your changes to less computer-savvy people.
That's pretty much the reason I started down the conda packaging road,
since there really wasn't a non-source-installation solution. Now you
could build your own conda package, upload it to a distribution channel
like anaconda.org, and have other people install it from there. That's
work for you, but it's easy for other people. If you want examples of
how to do that, see any of the OOT modules I have on
github.com/radioconda, e.g.
https://github.com/radioconda/gr-paint/blob/conda/.conda/README.md
Following that README, I have the OOT modules set up to build packages
with Github Actions and upload them to anaconda.org, from which I
include them in the radioconda installer.
Once you've had to invoke all of that developer machinery, it's really
not much harder to deal with a C++ OOT module compared to a Python one.
But if you do end up with the latter, then you could look at the
radioconda fork of gr-adsb to see how to reduce the build matrix when
you don't have to actually compile anything.
Cheers,
Ryan
No comments:
Post a Comment