RE:building manpages via setup.py
> Simplest I can think of would be to build the extensions inplace > followed by the call to build_man. Something like: > override_dh_auto_build: > dh_auto_build > python3 setup.py build_ext --inplace > python3 setup.py build_man I do not want to build once more the ext (it takes a lot's of time on my computer and it is a wast of ressources). I just want to run {interpreter} setup.py build_man where are provided by pybuild > I left the http_proxy exports and nodoc guards out for clarity. thanks ;) > Second questions what is the right way to generate the man pages for a > python application ? > Usually via Sphinx if the upstream documentation uses it. Regardless of > the stack, `help2man` is often considered the poor man choice for > generating manpages. Thanks, I know this but I need more time to convince the upstream to find a better solution :) > Let me know if you'd like me to have a look :-) thanks a lot Fred
Re: building manpages via setup.py
[PICCA Frederic-Emmanuel, 2017-08-01] > This pacakge contain one module with extensions (the important point) > > The new upstream version 0.14.0 provide a build_man target via the setup.py > > So in ordert to generate the doc I need to do > > python setup.py build_man > [...] > So what should I do to run > > python setup.py build_man with the options provided by pybuild during the > normal build in order to let the generated script find the pyFAI modules and > its extensions ? if you want it to be run only once (for default Python 3 interpreter): | override_dh_auto_build: | dh_auto_build | pybuild --system=custom --build --build-args '{interpreter} setup.py build_man' --interpreter=python3 if you want to test all requested Python interpreters: | override_dh_auto_build: | dh_auto_build -- --after-build '{interpreter} setup.py build_man' there's no need to prepend --after-build argument with "env PYTHONPATH={build_dir}; " - pybuild sets that to build dir automatically -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: building manpages via setup.py
On 01/08/17 15:15, PICCA Frederic-Emmanuel wrote: Hello, I am working on the pyfai package. This pacakge contain one module with extensions (the important point) The new upstream version 0.14.0 provide a build_man target via the setup.py So in ordert to generate the doc I need to do python setup.py build_man Now if I look at this target, I can find this code - class BuildMan(Command): """Command to build man pages""" user_options = [] def initialize_options(self): pass def finalize_options(self): pass def entry_points_iterator(self): """Iterate other entry points available on the project.""" entry_points = self.distribution.entry_points console_scripts = entry_points.get('console_scripts', []) gui_scripts = entry_points.get('gui_scripts', []) scripts = [] scripts.extend(console_scripts) scripts.extend(gui_scripts) for script in scripts: elements = script.split("=") target_name = elements[0].strip() elements = elements[1].split(":") module_name = elements[0].strip() function_name = elements[1].strip() yield target_name, module_name, function_name def run(self): build = self.get_finalized_command('build') path = sys.path path.insert(0, os.path.abspath(build.build_lib)) env = dict((str(k), str(v)) for k, v in os.environ.items()) env["PYTHONPATH"] = os.pathsep.join(path) import subprocess status = subprocess.call(["mkdir", "-p", "build/man"]) if status != 0: raise RuntimeError("Fail to create build/man directory") import tempfile import stat script_name = None entry_points = self.entry_points_iterator() for target_name, module_name, function_name in entry_points: logger.info("Build man for entry-point target '%s'" % target_name) # help2man expect a single executable file to extract the help # we create it, execute it, and delete it at the end py3 = sys.version_info >= (3, 0) try: # create a launcher using the right python interpreter script_fid, script_name = tempfile.mkstemp(prefix="%s_" % target_name, text=True) script = os.fdopen(script_fid, 'wt') script.write("#!%s\n" % sys.executable) script.write("import %s as app\n" % module_name) script.write("app.%s()\n" % function_name) script.close() # make it executable mode = os.stat(script_name).st_mode os.chmod(script_name, mode + stat.S_IEXEC) # execute help2man man_file = "build/man/%s.1" % target_name command_line = ["help2man", script_name, "-o", man_file] if not py3: # Before Python 3.4, ArgParser --version was using # stderr to print the version command_line.append("--no-discard-stderr") p = subprocess.Popen(command_line, env=env) status = p.wait() if status != 0: raise RuntimeError("Fail to generate '%s' man documentation" % target_name) finally: # clean up the script if script_name is not None: os.remove(script_name) - As you can see this create a launch script for each entry point found in the setup.py and run help2man on it. For now I would like to use this setup.py without modification. So what should I do to run python setup.py build_man with the options provided by pybuild during the normal build in order to let the generated script find the pyFAI modules and its extensions ? Simplest I can think of would be to build the extensions inplace followed by the call to build_man. Something like: override_dh_auto_build: dh_auto_build python3 setup.py build_ext --inplace python3 setup.py build_man I left the http_proxy exports and nodoc guards out for clarity. Second questions what is the right way to generate the man pages for a python application ? Usually via Sphinx if the upstream documentation uses it. Regardless of the stack, `help2man` is often considered the poor man choice for generating manpages. Let me know if you'd like me to have a look :-) Ghis
building manpages via setup.py
Hello, I am working on the pyfai package. This pacakge contain one module with extensions (the important point) The new upstream version 0.14.0 provide a build_man target via the setup.py So in ordert to generate the doc I need to do python setup.py build_man Now if I look at this target, I can find this code - class BuildMan(Command): """Command to build man pages""" user_options = [] def initialize_options(self): pass def finalize_options(self): pass def entry_points_iterator(self): """Iterate other entry points available on the project.""" entry_points = self.distribution.entry_points console_scripts = entry_points.get('console_scripts', []) gui_scripts = entry_points.get('gui_scripts', []) scripts = [] scripts.extend(console_scripts) scripts.extend(gui_scripts) for script in scripts: elements = script.split("=") target_name = elements[0].strip() elements = elements[1].split(":") module_name = elements[0].strip() function_name = elements[1].strip() yield target_name, module_name, function_name def run(self): build = self.get_finalized_command('build') path = sys.path path.insert(0, os.path.abspath(build.build_lib)) env = dict((str(k), str(v)) for k, v in os.environ.items()) env["PYTHONPATH"] = os.pathsep.join(path) import subprocess status = subprocess.call(["mkdir", "-p", "build/man"]) if status != 0: raise RuntimeError("Fail to create build/man directory") import tempfile import stat script_name = None entry_points = self.entry_points_iterator() for target_name, module_name, function_name in entry_points: logger.info("Build man for entry-point target '%s'" % target_name) # help2man expect a single executable file to extract the help # we create it, execute it, and delete it at the end py3 = sys.version_info >= (3, 0) try: # create a launcher using the right python interpreter script_fid, script_name = tempfile.mkstemp(prefix="%s_" % target_name, text=True) script = os.fdopen(script_fid, 'wt') script.write("#!%s\n" % sys.executable) script.write("import %s as app\n" % module_name) script.write("app.%s()\n" % function_name) script.close() # make it executable mode = os.stat(script_name).st_mode os.chmod(script_name, mode + stat.S_IEXEC) # execute help2man man_file = "build/man/%s.1" % target_name command_line = ["help2man", script_name, "-o", man_file] if not py3: # Before Python 3.4, ArgParser --version was using # stderr to print the version command_line.append("--no-discard-stderr") p = subprocess.Popen(command_line, env=env) status = p.wait() if status != 0: raise RuntimeError("Fail to generate '%s' man documentation" % target_name) finally: # clean up the script if script_name is not None: os.remove(script_name) - As you can see this create a launch script for each entry point found in the setup.py and run help2man on it. For now I would like to use this setup.py without modification. So what should I do to run python setup.py build_man with the options provided by pybuild during the normal build in order to let the generated script find the pyFAI modules and its extensions ? Second questions what is the right way to generate the man pages for a python application ? thanks for your help Frederic
Re: updating packages
Christopher Hoskin writes: > What's the plan for moving them to unstable? Are they still using git > pq rather than git-dpm? I have updated celery to use git pq. Not done kombu or python-amqp yet however. -- Brian May
Re: updating packages
Great, thanks! What's the plan for moving them to unstable? Are they still using git pq rather than git-dpm? Christopher On 1 August 2017 at 09:22, Michael Fladischer wrote: > Hi guys, > > On 2017-07-29 12:48, Christopher Hoskin wrote: >> I was going to look at updating vine, kombu and python-ampq this >> weekend, but the upstream tarballs have been signed by a different key >> pair than the one advertised at: >> >> http://docs.celeryproject.org/en/latest/contributing.html#security >> >> which makes me reluctant to proceed until the Celery Project confirms >> that they're using a different key pair. > > I checked with upstream on the new signing key[0] and they confirmed it. > > amqp, kombu and celery have been updated and uploaded to experimental. > > [0] https://github.com/celery/kombu/issues/773 > > Cheers, > -- > Michael Fladischer > Fladi.at
Re: updating packages
Hi guys, On 2017-07-29 12:48, Christopher Hoskin wrote: > I was going to look at updating vine, kombu and python-ampq this > weekend, but the upstream tarballs have been signed by a different key > pair than the one advertised at: > > http://docs.celeryproject.org/en/latest/contributing.html#security > > which makes me reluctant to proceed until the Celery Project confirms > that they're using a different key pair. I checked with upstream on the new signing key[0] and they confirmed it. amqp, kombu and celery have been updated and uploaded to experimental. [0] https://github.com/celery/kombu/issues/773 Cheers, -- Michael Fladischer Fladi.at