What tripped you up when you first set up PhilanthroPy?

[shivamlalakiya]

Ten people have merged pull requests here in the last month, which means ten people cloned the repo, installed it, and got the test suite running without me watching. I'd like to know what was annoying about that.

Anything counts: the editable-install gotcha, how long make ci takes, working out where a class actually lives, the coverage gate rejecting a PR, an unclear docstring, a stale line number in an issue body. I'm not looking for praise and I'm not looking for polish. I'm looking for the thing you hit at 11pm that made you consider closing the tab.

Two reasons I'm asking rather than guessing:

1. I wrote the setup instructions, so I am the worst possible judge of whether they work. You all followed them recently enough to remember where they were wrong.
2. Onboarding friction is invisible to CI. Every gate in this repo is green, and that tells me nothing about whether a first-time contributor spent an hour confused before the first green run.

Reply here with whatever you've got, however small. If it's concrete enough to fix, open an issue instead and I'll label it. Both are more useful to me than silence.

[AsavariCharati]

Posted something similar on #74, but to add it here directly:

• make ci/make riskcov don't run out of the box on Windows since make isn't installed by default , had to run each Makefile command manually (flake8, mypy, doctest, pytest, coverage) one at a time.
• sh scripts/install_hooks.sh needs Git Bash, doesn't run in plain PowerShell.
• pytest --cov=... (pytest-cov) threw ImportError: cannot load module more than once per process on numpy import every time on my setup. Switching to coverage run -m pytest + coverage report avoided it entirely and gave the same numbers.

None of this blocked me, just extra steps I had to work out along the way , probably just a Windows vs. Unix-shell thing rather than anything wrong with the instructions themselves.

[shivamlalakiya]

@AsavariCharati this is the first reply either of this repository's Discussion threads has ever had, and it is worth more than the two-day wait suggests. Thank you.

All three are real, and none of them are a Windows-versus-Unix shrug. They are all "the instructions were written by someone who never ran them on your machine", which is the specific thing I cannot see from here.

1 and 2, make and install_hooks.sh: filed as #195, labelled good first issue and documentation, crediting you. The fix is documentation, not a make.bat. A second copy of the gate is a second thing to drift, and this project already has scars from that: #21 and #22 exist because CONTRIBUTING.md claimed an 85% coverage floor for months after the real number moved to 92%. So #195 asks for the Git Bash requirement to be stated next to the install_hooks.sh line, for the "run these one at a time" path to be named, and explicitly forbids pasting the Makefile recipes or the risk-tier floor into prose. Take it if you want it; you are the right person to write it. If you would rather not, it stays in the queue and someone else picks it up.

One thing worth knowing for your own workflow, and #195 asks the contributor to confirm it rather than trusting me: the installer needs a Unix shell, but the installed pre-push hook is a #!/bin/sh script that Git for Windows runs through its own bundled bash. So it should fire from PowerShell after that one Git Bash step. If it does not on your setup, that is a bigger finding than the install note.

3, the pytest --cov failure: please open that one yourself. I am not being polite. I cannot reproduce it and I cannot file a useful issue about it, because everything that would make it diagnosable is on your machine. ImportError: cannot load module more than once per process comes from numpy itself refusing a second initialisation in one interpreter, so the interesting question is what caused numpy to be loaded twice, and my guess is a .pth file: both coverage and pytest-cov install one, those run at interpreter startup before pytest does anything, and if two numpy copies are reachable on sys.path (a mixed conda-plus-pip environment does this often) the early import and the later one can resolve to different ones. That is a hypothesis, not a diagnosis. Plain pytest and coverage run -m pytest both working is consistent with it and does not prove it.

If you file it, the things that would settle it:

• Full traceback, not just the last line.
• python -VV and python -c "import numpy; print(numpy.__version__, numpy.__file__)".
• pip list | findstr /I "numpy pytest coverage" (or pip freeze).
• Whether the environment is conda, venv, or the system Python, and whether pip and conda have both installed numpy into it.
• Output of python -c "import sys; print([p for p in sys.path])" from the repo root.
• dir on your site-packages for anything matching *.pth.

If it turns out to be an environment collision rather than anything this repository controls, that is still worth an issue: the fix is then a line in CONTRIBUTING.md naming the symptom and the coverage run -m pytest workaround, so the next person recognises it in thirty seconds instead of an evening.

For the record, since you asked whether #188 already covered it: it did not. You are the first person to answer either thread, and what you found was three concrete things rather than "worked fine". That is exactly what the thread was for.