<RodolfoAzevedo>
Hello. I am having trouble using litex. I followed the install procedures and everything went fine. After that, I tried to execute the board demo (tang_nano_9k.py) and it complained: ModuleNotFoundError: No module named 'litex'
<RodolfoAzevedo>
Hello. I am having trouble using litex. I followed the install procedures and everything went fine. After that, I tried to execute the board demo (tang_nano_9k.py) and it complained: ModuleNotFoundError: No module named 'litex'
<josuah>
Hello RodolfoAzevedo! Did anything go wrong with this command? ./litex_setup.py --init --install
<josuah>
This is what was expected to install the various modules.
<josuah>
It will install everything to the current directory, so you might want to create a ./litex/ directory first
<josuah>
and then: cd litex
<josuah>
and then: ./litex_setup.py --init --install
<RodolfoAzevedo>
I added the --user option and it went fine
<josuah>
nice!
<RodolfoAzevedo>
I created litex, cd to it.
<RodolfoAzevedo>
and the --user in the command line: ./litex_setup.py --init --install --user
<RodolfoAzevedo>
without --user it does not work
<josuah>
what does this give to you? python --version
<RodolfoAzevedo>
python3 --version
<RodolfoAzevedo>
Python 3.8.6
<RodolfoAzevedo>
python --version
<RodolfoAzevedo>
Python 3.11.4
<RodolfoAzevedo>
I have oss_cad_suite installed
<RodolfoAzevedo>
with python3
<josuah>
oh, it looks like you have different python versions running around here
<RodolfoAzevedo>
should I install litex outside it?
<josuah>
python -m litex
<RodolfoAzevedo>
the 3.8.6 is oss_cad_suite version, the 3.11.4 is systemwide
<josuah>
python3 -m litex
<josuah>
do these two give you different result?
<josuah>
You are expected to get the same error message about 'litex' is a package and cannot be directly executed
<RodolfoAzevedo>
both give error,
<RodolfoAzevedo>
No module named litex
<josuah>
you might have to use the same python implementation that installed litex
<josuah>
which operating system is it/
<josuah>
s,/,?,
<RodolfoAzevedo>
I am using ubuntu 23.04
<RodolfoAzevedo>
it has that new thing on pip
<RodolfoAzevedo>
I can not pip to install
<RodolfoAzevedo>
(I think)
<josuah>
it tells you something about virtualenvs?
<josuah>
"This environment is externally managed"
<RodolfoAzevedo>
yes, pip complains about messing the system. It recommends using pipx
<RodolfoAzevedo>
Am I supposed to install outside any virtualenv or other environment?
<somlo>
I might be late to the party, and y'all have likely gotten it all figured out; but `--user` will install (links to) your litex & friends' python modules in ~/.local
<somlo>
*not* using `--user` will try (and likely fail) to install everything system-wide
<RodolfoAzevedo>
side note: I did it two months ago and it worked (even configured my board)
<josuah>
somlo: which might not work anymore as per python EXTERNALLY_MANAGED flag enabled for the system python, AFAIK
<josuah>
RodolfoAzevedo: what is the error message when trying to use pip?
<RodolfoAzevedo>
× This environment is externally managed
<RodolfoAzevedo>
╰─> To install Python packages system-wide, try apt install
<RodolfoAzevedo>
python3-xyz, where xyz is the package you are trying to
<RodolfoAzevedo>
install.
<RodolfoAzevedo>
If you wish to install a non-Debian-packaged Python package,
<RodolfoAzevedo>
create a virtual environment using python3 -m venv path/to/venv.
<RodolfoAzevedo>
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
<RodolfoAzevedo>
sure you have python3-full installed.
<RodolfoAzevedo>
If you wish to install a non-Debian packaged Python application,
<RodolfoAzevedo>
it may be easiest to use pipx install xyz, which will manage a
<RodolfoAzevedo>
virtual environment for you. Make sure you have pipx installed.
<RodolfoAzevedo>
See /usr/share/doc/python3.11/README.venv for more information.
<RodolfoAzevedo>
I tried again as fresh install without oss_cad_suite environment
<josuah>
somlo: to be honest, I am surprised that the python community did not want to tolerate per-use packages and pushes everyone to use virtualenvs for everything.
<whitequark[cis]>
per-use packages? do you mean pypackages?
<tpb>
Title: PEP 582 – Python local packages directory | peps.python.orgSelected dark colour schemeSelected light colour scheme (at peps.python.org)
<somlo>
I'm still using the ~/.local stuff installed (a long time ago) with `--user` on fedora; updating litex repos from git works fine as long as all the ~/.local stuff is still there
<josuah>
oh my bad, typo of mine!
<whitequark[cis]>
josuah: the problem is that if you have a global system binary, e.g. `/usr/bin/systemapplication`, and it uses Python, it will pick up both Python packages from `/usr`, as well as from `~/.local`
<somlo>
I get the occasional need to re-install when python versions change and the directory name under ~/.local goes obsolete
<whitequark[cis]>
this means that if LiteX installs some random dependency of it into ~/.local, it can break completely unrelated system packages
<somlo>
maybe ubuntu and other distros are getting more prickly with their python setups, dunno about that
<whitequark[cis]>
and I actually had this happen multiple times on my system, it is a PITA to debug
<josuah>
RodolfoAzevedo: you might need to lear about virtualenvs. I use python's venv or pdm (thanks to whitequark[cis]).
<RodolfoAzevedo>
I had it working two months ago. then I decided to use it in a course I am teaching this semester.
<RodolfoAzevedo>
I will look to virtualenvs
<RodolfoAzevedo>
thanks!
<josuah>
this likely came all of a sudden with a python update, maybe an automated one
<somlo>
I only have the litex stuff in ~/.local, any non-litex "dependencies" are installed as distro packages (I am a fan of distro packages, if I haven't made that clear enough in the past :P )
<josuah>
RodolfoAzevedo: that is for creating a virtual environment, and then you'd be able to use it with just `cd ~/litex; . .venv/bin/activate`, that is the rawest possible venv
<whitequark[cis]>
the main utility of using PDM is that you can check the lockfile, containing the actual solved package versions, into VCS, and have reproducible installs
<josuah>
whitequark[cis]: do you use `__pypackages__` with them?
<whitequark[cis]>
josuah: no, venvs only
<whitequark[cis]>
__pypackages__ PEP was rejected so I do not use them
<whitequark[cis]>
venvs are standard
<josuah>
thanks! this makes sense
<RodolfoAzevedo>
thank you. I will follow these tips
<RodolfoAzevedo>
Amaranth is the new migen, right? Litex install still requires migen?
<whitequark[cis]>
LiteX is a fork of Migen, Amaranth is a new language borrowing from Migen's syntax
<whitequark[cis]>
I am linking you the example because it shows the use of PDM; I am not suggesting you use Amaranth (if you want to use LiteX, at the moment, it's not very useful to you)
<whitequark[cis]>
note that the 2nd paragraph is currently being rethought
<somlo>
whitequark: "LiteX is a fork of Migen" -- maybe you meant "LiteX uses Migen" ? :)
<somlo>
or "is written in migen", or something :D
<whitequark[cis]>
I was fairly sure LiteX includes the source code of Migen and builds of it
<whitequark[cis]>
s/of/on/
<somlo>
migen is a dependency of litex, perhaps one of those things you don't want installed in your ~/.local (fedora has it packaged as an "official" rpm)
<whitequark[cis]>
ohhh I see, LiteX stopped doing that, uh, many years ago apparently
<whitequark[cis]>
I think back in 2015 or so when I first encountered LiteX it did that and I think it got changed shortly after; my apologies for the confusion
<whitequark[cis]>
this is actually relevant to my work on having LiteX be Amaranth-compatible because I thought I'd be able to modify of the vendored-copy-of-Migen-sources-in-LiteX but I guess that won't be the case
<somlo>
2015 was a bit before my time; so I understand what you're saying as "litex used to use a vendored/bundled version of migen, and it got unbundled in the mean time" or some such
<whitequark[cis]>
no, it was also renamed to be under the litex namespace
<whitequark[cis]>
this is functionally a fork
<somlo>
from where I'm looking at it, the problem is one of *porting* litex from migen to amaranth :)
<somlo>
it's like "rocketchip is written in chisel" === "litex is written in migen" (at least as of right now, no idea on how it evolved to be like that)
<somlo>
(and yeah, the rocketchip repo has a bunch of sub-repos pulling in chisel, sbt, and the kitchen sink, but that's neither here nor there :D :D)
<whitequark[cis]>
if rocketchip pulled in an entire copy of chisel and renamed it to be under "rocketchip" namespace I would consider that a fork of chisel, fwiw
<whitequark[cis]>
but since litex does not do that anymore (and I honestly have a hard time remembering exactly what happened a decade ago) none of this especially matters
<whitequark[cis]>
it would actually be easier if litex was 'written in litex', because then I would not have to consider doing questionable things like installing amaranth.compat under migen in the Python package namespace
<somlo>
whitequark: looks like one day in the near term future I might need to package https://github.com/amaranth-lang/amaranth as a fedora RPM (same as the way I have migen packaged currently) -- any death traps I should be aware of ? :)
<whitequark[cis]>
none I can think of
<whitequark[cis]>
you'll want to wait until the 0.4 release since most software is currently using a git checkout
<whitequark[cis]>
but this will change with the said release, which has many highly anticipated features
<somlo>
right, I'll most likely wait until litex can be viably built with amaranth as a dependency instead of migen
<whitequark[cis]>
I don't think you will see it built with amaranth instead
<whitequark[cis]>
neither me nor Florent have concrete plans for that
<whitequark[cis]>
instead, the current plan is to take the current amaranth.compat module out of Amaranth (it was deprecated since 2018) or even rewrite it so that LiteX could evaluate Amaranth as a replacement in a piecewise fashion instead of replacing the entire thing at once
<whitequark[cis]>
the reason is that LiteX has a lot of code and there is only one Florent, and it would take a lot of effort, more than can be spared, to revalidate literally everything on top of Amaranth
<somlo>
ok, maybe I misunderstood then -- the "amaranth.compat" module is what might end up as an alternative to today's "migen", then?
<whitequark[cis]>
no
<whitequark[cis]>
to try and clarify once again: I have no interest in maintaining amaranth.compat and I would like to remove it entirely. however LiteX is the largest potential user of amaranth.compat which was also precluded from using it due to certain technical constraints
<whitequark[cis]>
to align our interests, there is a plan to take amaranth.compat out of Amaranth proper, (perhaps to a separate repo, perhaps to LiteX), update it so that it does not have to be a part of upstream Amaranth, and let LiteX use it as Florent and the LiteX community see fit
<somlo>
oh so you're talking about litex *incorporating* amaranth.compat as a "glue layer" between litex (which expects things to look like migen) and amaranth (which can use amaranth.compat to *make things look like migen*) ?
<whitequark[cis]>
correct
<somlo>
I see; in that case, what I said: litex (post-amaranth.compat-assimilation, or whatever) will end up depending on amaranth instead of "old" migen
<somlo>
and then it will be possible to "viably build litex with amaranth instead of migen", and I will need amaranth to be a packaged rpm on fedora so I can do that without too much fuss :)
<whitequark[cis]>
yes. the misunderstanding there is that I thought you had envisioned some other use for Amaranth
<somlo>
I mean, once it exists as an rpm and someone installs it, they can do whatever *else* (besides litex) they want with it, I'm sure litex isn't the only thing it's for ;)
<somlo>
but thanks for helping clear things up, makes perfect sense in retrospect!
<whitequark[cis]>
no problem
<cr1901>
Yea, LiteX was a fork from Migen/MiSoC, and has changed so much since then that it effectively its own unique ecosystem that uses Migen as a git dep. What about updating litex_setup.py to point to a different Migen repo?
<somlo>
cr1901: litex_setup.py assumes none of the "significant" dependencies are installed, and pulls them all in (including m-labs/migen). You wouldn't *want* to point it at another migen repo unless/until the amaranth.compat thing whitequark was talking about actually happens)
<somlo>
having a *packaged* systemwide install of m-labs/migen (like on Fedora) is a different thing (I just edit out the part of litex_setup.py that pulls in migen explicitly, since I already have it available locally)
<cr1901>
Hmmm... I figured you could just rm -rf the existing migen repo and check out the new one. But I realize that actually breaks _my_ own setup as well where migen is a symlink to the copy I've kept around since 2015
<cr1901>
w/ all its history, branches, etc
<somlo>
m-labs/migen has slowed down *a lot* over the last few years -- there's the occasional maintenance commit (e.g. to support python 3.11), but what's in Fedora right now is practically equivalent to the current tip of the m-labs/migen git repo
<somlo>
admittedly, there *might* be a few things that changed since 2015 :)
<somlo>
and if you're not using fedora or simply run litex_setup.py, you essentially get the same thing
<cr1901>
I'm a little bit surprised if a Litex design builds w/ a Migen from 2015. I didn't think the language changed _that_ little since 2015.
<somlo>
personally, I'm no expert, only know enough to be a slight danger to myself :) But it's *infinitely* more legible than e.g. Chisel ;P
<gurki>
somlo: how much effort does litex / enjoy digital actually put into migen maintenance?
<somlo>
i.e, even if you're a [n]migen / amaranth n00b, one can still follow what's actually going on by reading the sources, which is most definitely *not* nothing :D
<somlo>
gurki: I think that's the entire point of whitequark and _florent_ working on adding a "glue layer" that would alow litex to use amaranth instead of migen
<gurki>
but why wouldnt people just continue developing migen?
<gurki>
as in: whats the problem with migen?
<somlo>
amaranth is actively maintained (by whitequark, mainly, afaik) -- and migen not so much, from my observation
<gurki>
well. theres a company ultimately making $$$ out of it, they could have sb do things :)
<gurki>
(sorry for jumping this conversation, i was not aware of this ...)
<somlo>
I'll have to step back and let others speak more authoritatively about that sort of thing -- I don't have any insider knowledge, just a rando on the internet issuing observation based opinions :D
<cr1901>
Programming does not exist in a technical vacuum
<somlo>
cr1901: 100% agree -- it's one of the main reasons I'm volunteering to package things for my distro of choice -- I like to know how the tools I use (or the dependencies of things I care about) hang together, where they come from, and their "health and sustainability" status...
<somlo>
which makes the current trend of "vendoring" I've noticed in many projects somewhat ... suboptimal (at least from that specific angle)