Re: List of all redundant / empty projects in DPMT / PAPT that should be removed (Was: Empty Salsa project: sphinxcontrib-bibtex (same with pybtex-docutils and petsc4py))
Hi, út 25. 9. 2018 v 12:08 odesílatel Andreas Tille napsal: > If it simplifies your work to delete the repositories I can provide full > URLs. I'd also volunteer to do the removal work if you give me > according permissions for say one single day. > thanks for this list. I deleted empty repositories and archived others. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: python-setproctitle is in DPMT and PAPT
Hi, so 22. 9. 2018 v 7:20 odesílatel Andreas Tille napsal: > I recommend removing the repository in PAPT to avoid confusion. > agree and done. Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: Request to join DPMT and DPAP
Hi, st 19. 9. 2018 v 23:15 odesílatel Jochen Sprickerhof napsal: > would like to join the DPMT and PAPT teams on Salsa. welcome :) -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: please add me to the python modules team
Hi, po 24. 9. 2018 v 14:42 odesílatel David Bremner napsal: > For starters I want to package dateparser (#907337). > > My salsa id is bremner > did you read our policy please [1]? [1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Upstreams dropping Python 2 support (Was: Re: Report from the Python BoF @ DebConf18)
On Wed, Sep 19, 2018 at 09:32:23AM -0400, Sandro Tosi wrote: > > This also means finding > > solutions for edge-cases such as astroid, whose 2.0 branch is the only to > > support Py3.7, but also drops 2.x support. > > this is becoming less of an edge-case and more the current situation > of several "core" python modules: drop python2 support (eventually > maintaining a LTS-like old release around for py2) in favor of a pure > python3 codebase. Latest example is matplotlib 3.0 released yday which > dropped python2 support (maintained only in the 2.x branch, which will > receive only critical fixes), and numpy will release soon a py3k-only > version. > > What did the team decide on this front? duplicating packages is not > always feasible (both from an archive and from a maintainership > perspective) I think for “popular” packages duplication is unavoidable. Sphinx 2.0 will also drop Python 2.7 support, so I am going to make the “sphinx” source package ship only python3-sphinx, and introduce the new source package (“sphinx-python2”?) which will ship only python-sphinx. Eventually I will also do a mass bug filing, but with the current 314 python-sphinx reverse build-depends it is clear that I will have to ship sphinx-python2 for quite some time. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upstreams dropping Python 2 support
Dmitry Shachnev writes: > Sphinx 2.0 will also drop Python 2.7 support, so I am going to make the > “sphinx” source package ship only python3-sphinx, and introduce the new > source package (“sphinx-python2”?) which will ship only python-sphinx. > > Eventually I will also do a mass bug filing, but with the current 314 > python-sphinx reverse build-depends it is clear that I will have to ship > sphinx-python2 for quite some time. Is there a reason why one would use Python2-sphinx instead of the Python 3 version? How often in these 314 cases it is not just used as an executable in d/rules? Cheers Ole
Re: Upstreams dropping Python 2 support
On Thu, Sep 27, 2018 at 11:58:28AM +0200, Ole Streicher wrote: > Is there a reason why one would use Python2-sphinx instead of the Python > 3 version? How often in these 314 cases it is not just used as an > executable in d/rules? One possible reason is when sphinx.ext.autodoc is in use for documenting Python code, and that code is Python 2 only. Also there may be custom Sphinx extensions written in Python 2. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: List of all redundant / empty projects in DPMT / PAPT that should be removed (Was: Empty Salsa project: sphinxcontrib-bibtex (same with pybtex-docutils and petsc4py))
On Thu, Sep 27, 2018 at 11:05:26AM +0200, Ondrej Novy wrote: > > > If it simplifies your work to delete the repositories I can provide full > > URLs. I'd also volunteer to do the removal work if you give me > > according permissions for say one single day. > > thanks for this list. I deleted empty repositories and archived others. Thanks a lot Andreas. -- http://fam-tille.de
Re: Upstreams dropping Python 2 support
On Thu, 27 Sep 2018 at 11:58:28 +0200, Ole Streicher wrote: > Is there a reason why one would use Python2-sphinx instead of the Python > 3 version? src:dbus-python has more Python 2 API than Python 3 API (some objects cease to exist in Python 3 builds). As long as python-dbus.deb exists, it's somewhat valuable for the Python-version-independent documentation in python-dbus-doc.deb to have been built with the Python 2 version of sphinx. smcv
Re: please add me to the python modules team
Ondrej Novy writes: > Hi, > > po 24. 9. 2018 v 14:42 odesílatel David Bremner napsal: > >> For starters I want to package dateparser (#907337). >> >> My salsa id is bremner >> > > did you read our policy please [1]? > > [1] > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > So yes, I missed the part about including a statement about accepting the policy. I don't really want to do that, because the policy needs some maintenance. It misses at least - the death of alioth - the transition away from git-dpm That might seem silly and legalistic to some, but if we're going to be strict about adherence to policy, then it makes sense that those documents should be as high quality as possible. All the best David
Re: Byte-compilation for pypy3
> > err again (sorry, to many things at once), I meant option 4 (I can
> > change dh-python to generate additional checks for pypy{compile,clean})
>
> That'd be pypy3{compile,clean}
this is now available in dh-python 3.20180927. Only postinst files are
checking for pypy3compile, though. py3clean in prerm will remove .pyc
generated by PyPy3 as well (so no need to call pypy3clean in there)
> OK, so, now to figure out the "magic" part (byte-compiling already
> installed modules when pypy3 is installed / removed.
>
> Should I run the runtime.d directory? Currently everything in that will
> only do things with cpython bytecode.
>
> Apps that aren't in dist-packages probably don't need pypy3 bytecode,
> unless they want to be run with pypy.
>
> Anything that tries to determine the version (e.g
> /usr/share/python3/runtime.d/public_modules.rtinstall and
> /usr/share/python3/runtime.d/public_modules.rtremove) looks like they
> would break if I told them the version was pypy3.
>
> So, I'm somewhat tempted to ignore runtime.d entirely, and just
> byte-compile /usr/lib/python3/dist-packages. That seems pretty hacky,
> though :/
I think we should create a separate runtime.d for pypy3 and a separate one
for bcep files as well while we're at it.
FTR: bcep files are used to describe files that py3compile should avoid.
F.e. files meant for Python >= 3.6 ('async' keyword, etc.) should not be
byte-compiled using python3.5 (see dh_python3's manpage for details or
python3-jinja2 and pylint3 binary packages for examples).
Since we will share dist-package directory, we'll need to describe
exceptions for pypy3compile. One way is to extend version range syntax
in current /usr/share/python3/bcep/ files but I'd rather have separate
/usr/share/pypy/bcep/ used by pypy3compile.
signature.asc
Description: PGP signature
