On Sun, 2017-04-16 at 18:09 +0200, Mattia Rizzolo wrote: > On Sun, Apr 16, 2017 at 05:50:54PM +0200, Hugo Lefeuvre wrote: > > I introduced an additional binary package for this script because I thought > > people cold have found it useful. But, right, everything considered I should > > better drop it. > > Wait a second before dropping this.. > > What would be the downside of having it in a separate package? I > concur that the "py-" prefix strikes as odd, but I otherwise generally > recommend keeping /usr/bin/* stuff out of python-* packages, while > keeping in the latter only the python module, for a bunch of reasons.
Let me quote that upstream README for you: ``` Run as a script $ python cpuinfo/cpuinfo.py Run as a module $ python -m cpuinfo Run as a library import cpuinfo info = cpuinfo.get_cpu_info() print(info) ``` Nowhere is there mentioned a `py-cpuinfo` executable. The instructions given upstream for command-line usage are via a separate wrapper script named `cpuinfo.py` or a module call. In fact, if you install `py-cpuinfo` in a venv: ``` python3 -m venv py-cpuinfo source py-cpuinfo/bin/active pip install py-cpuinfo ls py-cpuinfo/bin/ `` You will only find an entry-point called `cpuinfo`. So what you guys are proposing is to introduce a new wrapper script, in its own binary package, whose name is not endorsed by upstream, and which will end-up completely Debian specific. Am I really the only one in this team to think this proposal is a complete non-sense? > Surely I'm not the only one who would consider moving the file back to > python3-cpuinfo a step backward… I fail to understand how your anti-Python-3 feelings add anything constructive to this thread. Moving on. AFAIC, I happily use pytest or sphinx via their respective python[3]- pytest and python[3]-sphinx. I don't consider the lack of a dedicated pytest or sphinx binary package a step backward. Regards, Ghis
