How does one install this stuff? Pip is not a debian application!

[pbreuer]

The documentation on how to install seems to assume that pip is present, or installable. That is not the case on the linux distributions I am familiar with, which all require python applications to be installed via their own package managers, not via python's internal manager. If I run "% sudo python -m pip install --upgrade pip", for example, I get:
/usr/bin/python: No module named pip
nor is there any way I can see of installing one. Your instructions seem so full of untrue assumptions as to be gibberish. Provide simple standalone instructions for installing riscof in /usr/local, carefully explaining what is to be done (not WHAT! That is another huge fault of your texts! Provide teaching, not (failing) recipes). You should aim for a python script installed in /usr/local/bin, and just forget about compiling it if you know what's good for you - it's completely unnecessary with todays computers. It's not rocket science, so please stop complicating things via layer upon layer of required things. So far I have installed everything I can see to do with yaml (which is completely unnecessary - nobody needs to read data, that's what computers do) [and riscof complains I have yaml 6.x not 5.x! What does it expect me to do? Reverse time?]
Yes, there is no "ensurepip" module in a python-full install, And that exhausts the methods to install pip: " If your Python environment does not have pip installed, there are 2 mechanisms to install pip supported directly by pip’s maintainers:
ensurepip
get-pip.py
And yes, if I run python on get-pip-py, all that happens is

This environment is externally managed

To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.    
See /usr/share/doc/python3.12/README.venv for more information.

And NO, I am not going to install a temporary sandbox. If I install something it gets installed properly, system-wide or not at all. Life is complicated enough as it is.

In your source directory, provide a README with a section called BUILD and a section called INSTALL. Provide simple instructions there. Preferably provide a Makefile. If all the Makefile does is call python, I don't care. Provide complete documentation WITH the code, not on an endless chase through links to pages on the web, which point to other pages, and so on.

Just straighten out installation, please, the current state of things is hopeless, presumably for the common engineers' faults of "we like it complicated" and "we have no idea how to communicate". The answer to the latter is to imagine telling your grandmother (or me!), and stop talking to each other and listening to "that's fine" through pats on the back. It isn't. It's hopeless.

What are these "tests" supposed to create? I can see .S files, and I can happily expand the macros by guessing the appropriate header files (make SURE there is only one possible choice, or SAY!), and I can happily compile via gcc riscv from debian (except it won't compile cache control instructions you have stuck in there, but I don't care) to an elf object file, but to make that into some kind of loadable lump I need to put an elf header on it and state what the entry point is, and say where it is to be loaded, and define what memory areas it will want and where, and other minor things. WHERE are those things described in order that I may do them and not rely on a failing installation process that tries to be too clever for its own good? What test are you actually doing? Are you reading memory? Reading outputs? Reading a trace? What is the expectation? Where is the explanation IN THE CODE?

When you tell me what the entry point and load address is, I plan to run under verilator and see what happens. Perhaps then I might figure out what other files that seem to be wanted or build are for .. please be sure to explain all that in the README and INSTALL files, so that nobody has to rely on you.

Regards

PTB

[trdthg]

Hello, about the first issue you mentioned, I have also encountered problems with environment configuration before, and I am thinking of some ways to solve it
I created a Docker development environment, and I would like to know your thoughts on it. The link is here: riscv-non-isa/riscv-arch-test#576
It can at least solve the majority of various environmental dependency issues, but I also have to admit that installing Docker on certain systems is not convenient (and it requires root privilege, which some people may not like; I haven't tested it in other container environments like podman yet), so this may only be suitable for regular system users or GitHub Workspace enthusiasts

[pbreuer]

On Sun, 05 Jan 2025 19:28:43 -0800 MingZhu Yan ***@***.***> wrote: I created a Docker development environment, and I would like to know your thoughts on it. The link is here: riscv-non-isa/riscv-arch-test#576

Unfortunately (for you :-) I will not touch docker. Please make ordinary debian packages. They will install anywhere (yes, redhat, slackware ...). Binary debian packages are enough ... .. because given your binary package of any kind, not necessarily debian, even just a .tar.gz I can reverse engineer to source easily enough. The problem for me is that I need to know what the intention is, and the full binary will tell me that, whereas the documents on the site don't. I'll look at your docker environment, but it's the same problem for me - I have to reverse engineer it to figure what it is trying to do. Just tell me, don't code it up! I can make any package easily as soon as you tell me what you are trying to put where and why for what. But no how, please! How definitely not wanted! Regards, and thanks for the contact! Peter PS. I don't use git, so I am in the position of having no idea what to do with a "pull request"! Please tell me how to get hold of your code, along with a description of what it is intended to do (I imagine docker uses something like a makefile plus something like a list of dependencies and where to get hold of them, and that's what you will supply). Send it to me as an email attachment if that's easiest.