On Wed, Aug 02, 2017 at 12:10:05PM -0400, ba...@debian.org wrote:
> On Jul 30, 2017, at 02:41, Steve Langasek wrote:
> >> https://wiki.debian.org/Python/LibraryStyleGuide where it states:
> >>You'll want to have at least the following build dependencies:
> >>...
> >>python3-all
> >> b
On Jul 30, 2017, at 02:41, Steve Langasek wrote:
>> https://wiki.debian.org/Python/LibraryStyleGuide where it states:
>> You'll want to have at least the following build dependencies:
>> ...
>> python3-all
>> but the
>> python[,3]-all-dev
>> are never mentioned. So sorry, I di
> The snippet you quoted is not specific to extension modules but to the
> use of the autodoc feature, which requires the modules to be in the
> PYTHONPATH. The `sys.path.insert` hack is just here so that you don't
> have to specify PYTHONPATH yourself when running the upstream Makefile.
I just sa
On 02/08/17 10:45, PICCA Frederic-Emmanuel wrote:
First, that's very speculative. Second, that's upstream's problem.
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root,
> First, that's very speculative. Second, that's upstream's problem.
> The upstream Makefile and conf.py are likely generated by Sphinx itself
> via sphinx-quickstart. Did your upstream tinker with them that much that
> they cannot be trusted?
No this is just that does not fit well with extension
On 02/08/17 09:55, PICCA Frederic-Emmanuel wrote:
PYTHONPATH=. sphinx-build -N -b html
One can also use the sphinx-generated Makefile if available:
PYTHONPATH=$(CURDIR) $(MAKE) -C html
Both are simple one-liners and do not rely on pybuild.
Yes it works but this is fragile since th
> PYTHONPATH=. sphinx-build -N -b html
> One can also use the sphinx-generated Makefile if available:
> PYTHONPATH=$(CURDIR) $(MAKE) -C html
> Both are simple one-liners and do not rely on pybuild.
Yes it works but this is fragile since the organisation of the module can
change in the sourc
> At the end of the day, it is just a matter of providing an appropriate
> PYTHONPATH, regardless of whether pybuild is used or not.
Yes but to avoid the multiplications of way to provide this PYTHONPATH.
Is it possible to have the recommended way which works for modules and
extensions.
once ag
On 02/08/17 09:19, PICCA Frederic-Emmanuel wrote:
At the end of the day, it is just a matter of providing an appropriate
PYTHONPATH, regardless of whether pybuild is used or not.
Yes but to avoid the multiplications of way to provide this PYTHONPATH.
For the vast majority of packages, the cur
> Perhaps the LibraryStyleGuide should be updated to reflect on this
> change? I believe we are still advising explicit http_proxy /
> https_proxy exports prior to running sphinx-build.
And running sphinx-build does not work expecially if there is extensions in the
documentation.
sphinx-build sho
On 02/08/17 09:03, PICCA Frederic-Emmanuel wrote:
Perhaps the LibraryStyleGuide should be updated to reflect on this
change? I believe we are still advising explicit http_proxy /
https_proxy exports prior to running sphinx-build.
And running sphinx-build does not work expecially if there is ext
On 02/08/17 08:44, Piotr Ożarowski wrote:
[PICCA Frederic-Emmanuel, 2017-08-02]
you can drop it, PYTHONPATH and http_proxy should be set by pybuild
Is it true for jessie
I need to support jessie and stretch
And even debian7...
I didn't test it even for unstable, but IIRC pybuild exports
> export PYBUILD_AFTER_BUILD={interpreter} setup.py build_man
Thanks, The only drawback I see with this solution is that I want to run
dh_auto_build 2 times,
- 1 for the arch part (pyhon modules, extensions and manpages)
- 2 for the indep part (doc build)
nevertheless thans a lot it is flexxib
[PICCA Frederic-Emmanuel, 2017-08-02]
> > you can drop it, PYTHONPATH and http_proxy should be set by pybuild
>
> Is it true for jessie
>
> I need to support jessie and stretch
>
> And even debian7...
I didn't test it even for unstable, but IIRC pybuild exports those in
all steps since a long
On 2017-08-01 11:58, Christopher Hoskin wrote:
> What's the plan for moving them to unstable? Are they still using git
> pq rather than git-dpm?
No plan yet for an upload to unstable. amqp and kombu have quite a few
reverse dependencies and I did no have the time yet to try a rebuild on
them.
All
[PICCA Frederic-Emmanuel, 2017-08-02]
> > if you want to test all requested Python interpreters:
>
> I prefer this solution in order to check that the built extensions are
> working for all the python interpreters.
> The doc use autodoc so it is nice to have this functionnality
>
> | override_dh
Hello piotr
> if you want to test all requested Python interpreters:
I prefer this solution in order to check that the built extensions are working
for all the python interpreters.
The doc use autodoc so it is nice to have this functionnality
| override_dh_auto_build:
| dh_auto_build -- -
17 matches
Mail list logo
