Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8405 > unrolled thread

Cythonized files & Debian Policy

Back to article view | Back to linux.debian.maint.python

Contents

  Cythonized files & Debian Policy Víctor Cuadrado Juan <me@viccuad.me> - 2016-04-07 23:30 +0200
    Re: Cythonized files & Debian Policy Scott Kitterman <debian@kitterman.com> - 2016-04-08 01:00 +0200
      Re: Cythonized files & Debian Policy Paul Wise <pabs@debian.org> - 2016-04-08 05:40 +0200

#8405 — Cythonized files & Debian Policy

[Multipart message — attachments visible in raw view] — view raw

I have come across an upstream that ships both the cythonized .c file
and the .py source, on my ITP python-neovim-gui [1].

On #python @freenode I have been said that shipping both files is
standard practice, which seems to be backed by the python docs [2].

I understand the need to separate “bundled files for end users”, versus
“actual source release" (aka the need to separate the build step),
essential to both software freedom and the utilitarian view of working
with the source (to fix bugs, fork, etc).

I also understand that the Python folks don't want the end user to
depend on cython and all that means, so they choose the middle ground
of providing both files.

I haven't found previous talk on this, has this topic already been
brought to the Cython/Python folks before?

Cheers,


[1]:
https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git/
[2]:
http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules


-- 
Víctor Cuadrado Juan           me@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

[toc] | [next] | [standalone]

#8406

On April 7, 2016 5:29:14 PM EDT, "Víctor Cuadrado Juan" <me@viccuad.me> wrote:
>I have come across an upstream that ships both the cythonized .c file
>and the .py source, on my ITP python-neovim-gui [1].
>
>On #python @freenode I have been said that shipping both files is
>standard practice, which seems to be backed by the python docs [2].
>
>I understand the need to separate “bundled files for end users”, versus
>“actual source release" (aka the need to separate the build step),
>essential to both software freedom and the utilitarian view of working
>with the source (to fix bugs, fork, etc).
>
>I also understand that the Python folks don't want the end user to
>depend on cython and all that means, so they choose the middle ground
>of providing both files.
>
>I haven't found previous talk on this, has this topic already been
>brought to the Cython/Python folks before?

The presence of binary artifacts in the source tarball isn't a problem as long as the relevant source in preferred form of modification is also present and the binary can be built using tools in Debian.

The only way to reliably know if it can be built is to do so as part of the package build, so you should regenerate the binary file and install that in your package.

This occurs many places in the archive and isn't at all unique to cython/python.  I don't think there's an issue that needs discussion as long as the actual (pre-cython) source is included.

Scott K

[toc] | [prev] | [next] | [standalone]

#8407

On Fri, Apr 8, 2016 at 6:42 AM, Scott Kitterman wrote:

> The only way to reliably know if it can be built is to do so as part of the package build, so you should regenerate the binary file and install that in your package.

In addition, removing the generated files in `debian/rules clean` and
`debian/rules build` (before any of the upstream configure/build stuff
runs) is a good idea to make sure that the existing generated files do
not leak into the build process.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web