> They won't have /usr/bin/python unless they explicitly install > python-is-python3. Since no packages should depend on > python-is-python3, only Python users who work with unpackaged software > (Python developers and developer-adjacents) *and* learn about it will > have it. It means PETSc should work with systems that don't have python > in their path.
Perhaps adopting valgrinds model might be more appropriate in that case? They require you run autogen.sh (which I don’t know that we need), and then configure which runs in shell and does the configure. We don’t necessarily have to do all of our configure in shell, just find a suitable python and call configure_in_python.py. I don’t know how they get around not having to chmod+x the shell scripts however, maybe because configure.sh has the shebang (!# /usr/bin/env sh) in it already? Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Apr 18, 2020, at 1:15 PM, Jed Brown <[email protected]> wrote: > > Satish Balay <[email protected]> writes: > >>>> From the page: >>> >>> make sure package doesn't call python at build- or compile time (as there >>> won't be a python package and no python command in bullseye, only python3.) >> >> Sure this makes sense for building distro packages - so that they have >> correct dependencies. >> >> But its not indicative of user install not having /usr/bin/python. > > They won't have /usr/bin/python unless they explicitly install > python-is-python3. Since no packages should depend on > python-is-python3, only Python users who work with unpackaged software > (Python developers and developer-adjacents) *and* learn about it will > have it. It means PETSc should work with systems that don't have python > in their path.
