Sphinx theme package naming conventions
Hello, I am working to package sphinx_press_theme (ITP bug #996543). According to Python package naming conventions [1] proper binary package name for it would be python3-sphinx-press-theme. However, most of sphinx theme packages seem to be named $THEME_NAME-sphinx-theme (source package), resulting in names like python3-$THEME_NAME-sphinx-theme (binary package) [2]. Is it OK to follow [1] and stay faithful to upstream name, or should I rename both source and binary packages to match already existing sphinx theme package names? [1] https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names [2] https://packages.debian.org/search?suite=sid§ion=all&arch=any&searchon=sourcenames&keywords=sphinx Best, Andrius
Re: Sphinx theme package naming conventions
Hi Andrius! On Thu, Oct 21, 2021 at 10:26:53AM +0300, Andrius Merkys wrote: > Hello, > > I am working to package sphinx_press_theme (ITP bug #996543). According > to Python package naming conventions [1] proper binary package name for > it would be python3-sphinx-press-theme. However, most of sphinx theme > packages seem to be named $THEME_NAME-sphinx-theme (source package), > resulting in names like python3-$THEME_NAME-sphinx-theme (binary > package) [2]. > > Is it OK to follow [1] and stay faithful to upstream name, or should I > rename both source and binary packages to match already existing sphinx > theme package names? I would follow the naming policy and use python3-sphinx-press-theme. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Sphinx theme package naming conventions
Hi Dmitry, On 2021-10-21 14:38, Dmitry Shachnev wrote: > On Thu, Oct 21, 2021 at 10:26:53AM +0300, Andrius Merkys wrote: >> Is it OK to follow [1] and stay faithful to upstream name, or should I >> rename both source and binary packages to match already existing sphinx >> theme package names? > I would follow the naming policy and use python3-sphinx-press-theme. Thanks for suggestion! Best, Andrius
.egg-info for entry points during dh_auto_test
Hi, I'm working on src:pytest-lazy-fixtures and was trying to get the unittests to run but it seems that I have run into a problem that I'm not sure on how to fix it in a clean way. pytest-lazy-fixtures is a pytest plugin and registers itself through the Python entrypoints mechanism. In its unitests, it assumes that this registration has already happened but during dh_auto_test there is no .egg-info directory available. I could use "python3 setup.py develop -x" to generate it, but this registers the package in /usr inside the build chroot which I think is not the best solution. Is there an other, less intrusive way to register the entrypoint before running the tests? Thanks, Michael
Re: .egg-info for entry points during dh_auto_test
Hi Michael (2021.10.21_18:55:51_+) > pytest-lazy-fixtures is a pytest plugin and registers itself through the > Python entrypoints mechanism. In its unitests, it assumes that this > registration has already happened but during dh_auto_test there is no > .egg-info directory available. I could use "python3 setup.py develop -x" to > generate it, but this registers the package in /usr inside the build chroot > which I think is not the best solution. I looked at this recently for pytest-doctestplus. The lazy answer is to run the full test suite in an autopkgtest, not at build time. pytest also has a mechanism to register plugins through an environment variable, but I couldn't figure out how to get the test suite to work with that. If you do find a nice mechanism, we should probably apply it to the packaging of all pytest plugins. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
