[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]



Hi Victor and James!


>Upstream released python-neovim-gui_0.1.2.

>That depends on python-neovim >= 0.1.6, which I already have packaged
>and not uploaded, since python-neovim depends on neovim >= 0.1.3,
>currently unreleased git master branch, which is changing.
>
>We could send the tagged python-neovim-gui_0.1.1 to NEW, as it works
>with Debian's neovim_0.1.2 and python-neovim_0.1.2, but this version
>has some quirks that I would like to be fixed prior to shipping it. [1]


James, do you have any showstoppers for neovim 0.1.3? in experimental?

I would like to avoid an old python-neovim-gui just because 0.1.3 isn't packaged
yet.

It has been released 6 days ago, so we can wait a little more if James agrees!

>Therefore, I have imported the new upstream version 0.1.2, which fixes
>some of the problems on the review, but we can't ship until we have
>neovim_0.1.3.


as said before, new queue is pretty fast nowadays, and python packages are easy to
review... we can wait I think


>> please add them as build-dependencies and check that python3:Depends do its job
>
>Fixed.
>* Added neovim check.
>* python3-click is only present on testing and unstable as 6.2, I have
>   added the check but it could be dropped.
>* pygobject is provided by python3-gi-cairo, python3-cairo,
>   gir1.2-gtk-3.0 as jpleau and I tracked down [2][3].


no. You need to add them to build-dependencies, remove them from runtime-dependencies and
verify python3:Depends is actually adding them. (by opening the built deb file and checking the debian/control inside).


install_requires is parsed during build, and information is extracted and converted in needed runtime
Debian packages.
(feel free to keep them in both build-dependencies and runtime-dependencies if the version is not correctly parsed)
(see borgbackup git history of debian/control file)

>Already upstreamed on 0.1.2.
>I haven't added the install inside setup.py since I wasn't sure it of
>the best way to make it work on all downstreams.


ok

>New version now ships a neovim_gui/screen.c. After a conversation at
>#debian-mentors and #python, Debian side I concur that we shouldn't
>be shipping it and that upstream should include the cythonize on the
>build, yet python docs say "distribute both .c and .py, don't build"
>[6]. I will leave the .c there for now.


ok
>Documented it on the commit message, please tell me if it's enough [4].

ok

>Reported upstream, where I will tackle it [5].


ok

>X: python3-neovim-gui: library-package-name-for-application usr/bin/pynvim
>
>Should we rename the package as `pynvim` and move it to DPAT instead of
>DPMT, even if it is provided by PyPi's module `neovim-gui`?

is it more a module or an application?


I guess an application, so maybe the applications team is more appropriate
you cant do something like
python3
import neovim-gui, right?

pynvim 
Traceback (most recent call last):
File "/usr/bin/pynvim", line 5, in <module>
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'


^^ another issue, you need pkg_resources too.

lets wait for neovim, in the meanwhile can you please fix the above points?

Gianfranco


Reply to: