Why do I keep getting this error when running the basic setup?

Look, before you post a wall of text here and waste everyone's time: read the logs, check the official documentation (which is extensive), search the forum for your specific error code — it has almost certainly

The most common reason is that you're using Python 3 but calling python instead of python3, which points to a SystemPython install with no permissions for your user. Try these in order:

1. Check versions: python --version && python3 --version. If they differ, use python3 explicitly.
2. Create a venv: python3 -m venv .venv && source .venv/bin/activate. This isolates dependencies from your system install.
3. Re-run the setup with pip inside the venv.

The "basic" tutorials often assume you're on a Linux system where python maps to 2.x by default, which is increasingly rare on modern installs.

This is the third time I've seen someone ask about the basic setup script. Read the logs — there is literally a line in your traceback that tells you exactly which dependency version is clashing with what. The whole thing is on page 4 of the docs, and there is an entire

I've seen this pattern before and it usually points to one of several cascading failure modes that all produce a superficially similar error but require fundamentally different remediation strategies, so we should systematically isolate which layer is actually broken rather than guessing at the obvious candidates first. The most common culprit in these basic setup scenarios is an implicit dependency resolution ambiguity where your package manager has decided on a version of a transitive library that conflicts with your environment's existing installation state even though no explicit version constraint exists in your top-level configuration, which effectively creates a diamond-dependency problem that the resolver can't unwind. Another possibility is environmental variable shadowing — you might have an old PATH or some other config exported at shell startup that takes precedence over what you think you're configuring -- I've seen this happen with people who've migrated from one project to another on the same machine and left a stale PYTHONPATH or MINGW_HOME pointing somewhere unrelated. The third vector is permission-related, though less common in basic setup: some installers drop files into directories that your current user doesn't have write access to but where you assumed standard permissions applied because nothing failed early enough -- it silently fails the file creation and then throws an opaque error when a later step tries to read what was never written. There's also a chance of a compiler version mismatch if you're building from source, where your system's default clang or gcc is too new for some older headers but not old enough to be backwards-compatible in the way the build script assumes -- this creates weird preprocessor errors that look like code bugs. To diagnose: run with verbose flag enabled at the lowest level possible so we can see the actual stack trace, dump your PATH and PYTHONPATH to a file for inspection against what you expect, verify the checksums of installed artifacts if applicable, and try running in an isolated environment (venv/container) to rule out system-wide pollution. If it works in isolation, then we know the

I'm going to assume you didn't just copy-paste the entire stack trace without reading it, because if you did that would be a problem and I don't have time for that today. The error is literally three lines up from where your question starts — it says permission denied

Usually it's just permissions — check sudo.

This is the classic symptom of what I like to call the cascading dependency version mismatch, which is arguably one of the most structurally interesting failure modes in package management because it exposes a fundamental tension between semantic versioning guarantees and transitive resolution. Let me walk through exactly what's happening under your hood here before we get into the fix.

Your basic setup script invokes pip install -r requirements.txt, which reads twenty-two top-level dependencies, but each of those has its own tree of sub-dependencies, so you're actually pulling in approximately four hundred individual packages. Now — and this is where it gets interesting from a systems perspective — your package manager resolves these by constructing a directed acyclic graph (DAG) of every dependency, applying version constraints at every node, and attempting to find a set of concrete versions that satisfies the entire intersection of all those constraints simultaneously. That's essentially an SMT solver problem in disguise.

The error you're seeing is a version conflict: package A requires >=1.2.3 of a shared library, but your requirements file explicitly pins it at 0.9.8 from some legacy module, and there exists no valid solution in the current resolution space that satisfies both constraints because they are mutually exclusive on the same leaf node of the DAG. You could have fifteen hundred packages loaded correctly while one single edge in the dependency graph points to an incompatible version specifier, and pip will balk at it entirely — it refuses to pick a winner arbitrarily because doing so would violate your explicit pinning and potentially break your build silently, which is actually a good thing from a correctness perspective even though it's frustrating on a Tuesday afternoon.

The fix involves one of three things depending on how much you care about reproducibility versus speed. Option one: use pip-compile (from poetry's tooling) to generate a pinned lockfile that resolves all transitive dependencies upfront so the error surfaces at build time rather than install time. Option two: relax your