RE:building manpages via setup.py

2017-08-01 Thread PICCA Frederic-Emmanuel
> 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

2017-08-01 Thread Piotr Ożarowski
[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

2017-08-01 Thread Ghislain Vaillant

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

2017-08-01 Thread PICCA Frederic-Emmanuel
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

2017-08-01 Thread Brian May
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

2017-08-01 Thread Christopher Hoskin
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

2017-08-01 Thread Michael Fladischer
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