Re: Updating python-build/getting rid of pep517
Le 02/08/2023 à 00:09, Scott Kitterman a écrit : * pdm (update to new version, needs pyproject-hooks) [pdm-pep517 can probably go away too] pdm-pep517 was renamed to pdm-backend, which will still be needed by Python packages who want to use it as a build backend. (It does not depend on pyproject-hooks.) Cheers
Re: Help with numpydoc needed (Was: Bug#1029245: nitime: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13)
Le 20/01/2023 à 16:21, FC Stegerman a écrit : Should that not use "func" instead of "inspect.getframeinfo"? Yes of course! I tested in a terminal to give valid code and forgot to replace my example function with the original variable name. Thanks!
Re: Help with numpydoc needed (Was: Bug#1029245: nitime: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13)
Hello,
Le 20/01/2023 à 15:33, Andreas Tille a écrit :
I finally do not have an idea how to replace:
Handler for event
'autodoc-process-docstring' threw an exception (exception: 'FullArgSpec' object has
no attribute 'replace')
which you can find in the latest build log in Salsa CI.
tl;dr: replace the body of the try block with this:
argspec = inspect.signature(inspect.getframeinfo)
argspec = str(argspec).replace('*', '\\*')
signature = '%s%s' % (func_name, argspec)
The code does a string replace so that `*` characters in the function
signature (used for variadic args, variadic keyword args and separating
keyword-only args) get escaped to prevent interpretation by Sphinx as
emphasis markup.
The inspect.getfullargspec function returns a special object (a named
tuple), not a string. On the commented line in the patch, we see a call
to format.formatargspec which was meant to turn the FullArgSpec into a
string, but that function has been deprecated since 3.5, with an error
message pointing to the newer, better API: function signatures.
Cheers
Re: [DRAFT] DPMT and PAPT is DPT now
Hello, Le 2020-09-14 à 17 h 42, Christian Kastner a écrit : > PAPT and DPMT become DPT > > > Historically, the Debian Python ecosystem was maintained by two separate > teams: the Debian Python Applications Packaging Team (PAPT) for > applications, and the Debian Python Modules Team (DPMT) for modules used > by applications. There’s also the CPython interpreter itself, maintained by a solo developer for a long time, more recently a third team. Regards
Re: Compiled C modules are not found by test suite (Was: Help needed for python-biopython which splits up modules into two packages per Python version)
Hi, I tried the first solution and did not see a difference in tests: both times, 223 tests were run successfully. I’d like to reproduce the errors you mention to be sure that any change I make is actually a fix. I guess this is the solution since if the C modules are not found the test is just skipped (and does not fail). I expected to see fewer tests run when the C modules are found. I was not able to find one example test that runs if a C module is found and skipped if not. If you could provide this very patch I'd be really glad. Run “python build_ext --inplace build test” for tests, “python install” to copy all files to the debian/tmp/etc directory. This will avoid the other bug I mention (http://bugs.python.org/issue5977#msg213606). I did not use the debian/rules makefile, but modifying line 45 to add “build_ext --inplace build” before “test” should do the trick. (Putting the option in a setup.cfg file as I initially advised would cause the error I alluded to when running “setup.py install”.) Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53242318.4090...@netwok.org
Re: Compiled C modules are not found by test suite (Was: Help needed for python-biopython which splits up modules into two packages per Python version)
Hello, I got the code and the debian directory. I confirmed that extension modules are in the build directory, not alongside the Python modules, so they can’t be imported from tests. There are two ways to fix that: either make distutils build the extensions alongside the Python modules, or make the test import all code from the build directory. I’m surprised that this isn’t a common issue for PMPT. I tried the first solution and did not see a difference in tests: both times, 223 tests were run successfully. I’d like to reproduce the errors you mention to be sure that any change I make is actually a fix. Unfortunately, there is a long-standing bug in distutils where extensions modules built alongside the Python modules are not found by the install command. This means that you’d have to compile twice (once in-place to run the tests, one to a build directory to install to debian/tmp/etc.), or that you’d prefer the other fix. Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53238d8e.4070...@netwok.org
Re: Compiled C modules are not found by test suite (Was: Help needed for python-biopython which splits up modules into two packages per Python version)
Hello, Le 05/03/2014 10:31, Andreas Tille a écrit : I have noted another problem: I worked a bit on the tests and noticed that those tests that are including compiled C code are failing. Is there anything in addition I need to do to make the C object code visible to the Python modules? Can non-DD see the source code somewhere? IIUC you have a Python package and C extensions; when running the tests during the package build (or is it against the installed package?), the C extensions are not found. One explanation for that could be that the C extensions are built in a “build” directory instead of inside the Python package, and thus aren’t readily importable. If the build uses distutils/setuptools, there is an option to control that: # file setup.cfg next to setup.py [build_ext] inplace = 1 Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531feea6.6040...@netwok.org
Re: Specifying ‘--install-data’ for each binary package
Hello,
Le 02/09/2013 09:32, Ben Finney a écrit :
Those files are specifically declared in the ‘setup.py’ call via the
‘package_data’ option. To tell Distutils where those files go,
URL:http://docs.python.org/2/install/index.html#custom-installation
says the correct command-line option I should use is
‘--install-data=usr/share/${PACKAGE_NAME}’.
Are you sure? package_data files are installed alongside the Python
modules; I think --data-files only controls the files declared as
data_files.
http://docs.python.org/2/distutils/setupscript#installing-package-data
vs.
http://docs.python.org/2/distutils/setupscript#installing-additional-files
Regards
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5224c69c.2020...@netwok.org
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz - v.2
PEP390 That one is retired. setup.cfg is defined by documentation, not a PEP. Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50661617.40...@netwok.org
Re: RFS: python-formalchemy
Hello everyone, Le 22/08/2011 12:43, Piotr Ożarowski a écrit : FormAlchemy (as way too many other Python modules) adds data files (images, templates, locales, etc.) to site-packages directory, we try to move them to the right location whenever possible, Could you point me to more info about this? I haven’t read all of the Debian Policy yet, just the FHS and the Debian Python Policy (which states things without giving rationale, unfortunately), so I’d appreciate pointers. When we talk about this on python-dev, some people argue that a Python package should be free to have modules and data files in its directory, and that putting them in different locations is arbitrary. Without going all the way to NextStep-style applications that are fully contained in one directory with duplicated libraries and dependencies, which I highly despise, I do see their point. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e535351.8040...@netwok.org
Re: Bug#563391: Package Trac 0.12 as well
- Is the run-time dependency on python-setuptools required (or should it only be Build-Depends)? python-setuptools is indeed used by Trac (at least in 0.11), maybe for the plugins. Don't touch it :~) Are you sure the full python-setuptools is required, not only python-pkg-resources? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1b14d0.40...@netwok.org
Re: Current state of packaging Python software for Debian
Hi, Le 01/07/2011 16:07, Barry Warsaw a écrit : On Jun 15, 2011, at 05:07 PM, Éric Araujo wrote: Yes, last summer’s GSoC added a test command, which defaults to unittest(2) test discovery and can be configured to use any test runner on any test suite. It runs tests against the modules in the build directory, to be able to work with code converted at build time with 2to3 (and soon, to be able to access the PEP 376 dist-info files). Barry, I’m waiting for reports about the problems you ran into :) IIRC, they were problems with doctests not getting properly converted, but I forget the details at the moment. I'll try Python 3.3/packaging again soon and definitely file bugs for anything I find. Can I use the Python tracker for those? Certainly, using the Distutils2 component and 3.3 version. Tarek, Alexis and I will get auto-nosied. Regarding Sphinx, I don’t think it would be appropriate to add a command for it in the stdlib. We already have upload_docs, which can upload any set of HTML files. Well, almost. I think there are some problems with that in Python 2, such as if the Sphinx docs aren't laid out in the particular way expected by `upload_docs`. E.g. say you don't have an index.html file but you do have a README.html. upload_docs merely complies with the Cheeseshop rules: http://wiki.python.org/moin/PyPiHostingDocumentation However, it’s much easier to add custom command in packaging¹, so Sphinx’ distutils-based build² command can be used with pysetup. That probably makes sense given that Sphinx is a separate project, but whatever we can do to make it easy to use the de-facto standard, the better. For example, `python setup.py build_sphinx` is a pretty lousy command name, but that's Georg's problem. ;) OTOH, if packaging supports command extensions, then `pysetup build` should Just Work to build the docs too, when Sphinx is installed and docs are written in reST. Yes, automatic registration of commands and subcommands is one of the goals of Tarek. Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0f3163.6090...@netwok.org
Re: Python Multi-Build for Python Extensions Packaging - Report 2
One of the important BuildSystem class method is detect method. This method will detect the extension's build system. If given directory has files for building extensions for this build system (or other magical detecting ways) it will return true. In packaging/distutils2, we have code to detect whether a project uses distutils, setuptools or packaging: http://hg.python.org/cpython/file/a7e00934baf1/Lib/packaging/util.py#l1343 Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dfe1305.4050...@netwok.org
Re: Current state of packaging Python software for Debian
Hi, [Barry Warsaw] [Zygmunt Krynicki] Can please we have standardized hooks to build sphinx documentation and run setup.py test tests? I'd like to see the packaging folks address this. Eric is subscribed to this list and can probably speak to packaging's take on it, but my preferences would be that $ pysetup test would run all the tests in Python 3.3 and beyond (and in a distutils2 world). I don't think this is supported (yet?), and my limited testing required some 2to3 hackery that isn't quite working. Yes, last summer’s GSoC added a test command, which defaults to unittest(2) test discovery and can be configured to use any test runner on any test suite. It runs tests against the modules in the build directory, to be able to work with code converted at build time with 2to3 (and soon, to be able to access the PEP 376 dist-info files). Barry, I’m waiting for reports about the problems you ran into :) Note that our implementation of test and 2to3 conversion is quite different from setuptools/distribute’s. For one thing, we use regular command options in the config file or on the command line, not global setup() arguments (and now setup() is gone anyway). I’m greatly responsible for that, because I believe it’s much cleaner. Regarding Sphinx, I don’t think it would be appropriate to add a command for it in the stdlib. We already have upload_docs, which can upload any set of HTML files. However, it’s much easier to add custom command in packaging¹, so Sphinx’ distutils-based build² command can be used with pysetup. ¹ http://docs.python.org/dev/packaging/setupcfg#global-options ² Why isn’t it named build_docs?! [Ben Finney] AFAICT it *is* the de facto standard. Perhaps you mean that you want it to be the de jure standard? What change are you wanting on this? In some sub-communities, py.test or nosetests are the standard, not setup.py test. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df8cab9.8040...@netwok.org
Re: Current state of packaging Python software for Debian
Le 15/06/2011 10:18, Zygmunt Krynicki a écrit : W dniu 15.06.2011 03:28, Ben Finney pisze: If we are talking from a perspective of upstream developers that also maintain their packages then I would *love* to see setup.py sdist-test and would use it each day. ;-) How would a putative ‘sdist_test’ differ from ‘test’? Why is this an argument for a new command, and not an argument to improve what is done by ‘test’ anyway? Pure test runs the test on the check-out of the code and is usually invoked by the upstream developer. It can (and often does) run on a superset of files that are distributed with sdist). In contrast, the theoretical sdist_test would first create a release tarball with sdist, unpack it to some temporary directory and run `setup.py test` there. I’m sympathetic to the idea (one nit: it would be a new option to the test command, not a new command). It can be done today by manually unpacking sdist, going to that dir and running test, but wrapping that in a packaging/distutils2 command would not harm. Such a command would be useful for checking that project manifest file contains everything desired to make the program run correctly (I often miss something and only realise it's missing when I start packaging). This has bitten so many people that I’m definitely +1 on doing something here. We already have a check command to perform some checks on the contents of setup.cfg (or setup.py in distutils 2.7 and 3.x); I’d bet a standard way to verify the sdist between build and upload would become a favorite command very fast. On the other hand, we cannot and should not try do too much in a packaging command; people want to check unpacking, run the test suite, check installation, and possibly other things which IMO fall under the scope of tools like tox. But trying to import all modules, checking the list of files and running tests are definitely things that we can discuss for the stdlib. On a related note, a virtualenv-style isolation feature is planned for Python 3.3. With the building blocks provided in the packaging module and that feature, it should be easy to make a tox-like tool to perform checks on sdists. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df8cedc.4080...@netwok.org
Re: regarding Packaging module in 3.3
Le 14/06/2011 14:40, Tshepang Lekhonkhobe a écrit : Have you guys looked at the new module, Packaging, in Python 3.3? Will it solve all the problems that Debian Python packaging has, or is it still lacking? distutils2/packaging is an improved fork of distutils. As such, it will not revolutionize Debian packaging, but we’re willing to help downstream packaging as far as possible. For example, I’d like to remove the need for the install-layout=deb patch to distutils. Also, I’d like to improve the compileall module to better support Debian’s needs, and also reach agreement on adding a vendor-packages directory (http://bugs.python.org/issue1298835), and work on any other bugs in site, sysconfig or other modules that Debian has to patch. distutils/packaging is only one part of the overall installation system. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df7731c.60...@netwok.org
Re: list of package for python_support - dh_python2 ?
Paul Wise p...@debian.org writes: Personally I've always wondered why a Debian-specific helper should be needed instead of python upstream behaving the way we wanted. I’m curious about the distutils monkey patches and the lack of use of the standard compileall module. The Python bug tracker is open hintwink. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df22c8e.1090...@netwok.org
Re: RFS: decoratortools
Hi, Thanks for the replies; I will probably look into decoratortools to see its cool features. I may request some of them on bugs.python.org, don’t hesitate to do the same :) Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de6786e.10...@netwok.org
Re: RFS: decoratortools
Hi, python-decoratortools - version-agnostic decorators support for Python I’m curious about the usefulness of this package. Special syntax for function decorators is built-in in Python 2.4+ and the class counterpart is available in 2.6+ and 3.x. Why would we need support for older versions that the ones in the archive? Best regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de3a229.4080...@netwok.org
Re: Switching to git
Le 06/03/2011 23:30, Yaroslav Halchenko a écrit : On Sun, 06 Mar 2011, Nicolas Chauvat wrote: Mercurial works well with multiple repositories (subrepo extension) ah thanks -- at times I need to look at HG repos, and I could not figure out how to get multiple 'remotes' I don’t think git remotes are like hg subrepos. IIUC, git remotes are paths to remote repositories; in Mercurial, that’s done by adding entries to the paths section of the repo’s .hg/hgrc file. Mercurial subrepos are something like Subversion externals or git submodules. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d748ed3.90...@netwok.org
Re: [Python-modules-team] Dependencies for python2.6-only packages (best practice)
Following up #606711, I'd like to ask what's the best way to tailor python dependencies for a package when it's content is a backport of a future Debian default python (e.g. 2.7) feature? In the case of importlib, it's inclusion in upstream python started with 2.7 but I'd like to provide the backport for at least 2.6. This is not relevant to the question about the toolchain that you were asking, but I’d like to point out that importlib in 2.7 is only a subset of the version in 3.1 (precisely, importlib.import_module only), so packaging a full backport of importlib makes sense for 2.7 too. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3860eb.80...@netwok.org
Re: distutils and -fno-strict-aliasing
Hi Jakub, Can you report this behavior on bugs.python.org, if it isn’t already filed? Thanks in advance. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d05484a.1010...@netwok.org
Re: Untrusted search path vulnerabilities
Hello, * python2.7-examples (2.7-9) * python3.1-examples (3.1.2+20100926-1, 3.1.2+20101012-1) * python3.2-examples (3.2~a3-1) For the person reporting those: If they need to be forwarded upstream, feel free to cc: me in the bug report and I’ll do it. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce45397.4060...@netwok.org
Re: Bug#589759: debhelper: dh_auto_install + python-all-dbg changes shebang of scripts
Hello You can control the shebang through an option: python-dbg setup.py build --executable /usr/bin/python This is distutils behavior, I don’t know how setuptools script generation works. Hope this helps. By the way, I don’t know the standard practice for replying on this list, so I’m not cc’ing anyone. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c4625ad.8040...@netwok.org
Re: XS-Python-Version: current fix
While current is frowned upon[0], this is not what caused your package breakage. The culprit it that scripts have #!/usr/bin/pythonX.Y shebangs - if they were unversioned, the package would continue to work with new Python. Those are changed by python distutils, that's why a rebuild fixes the problem. You can pass an option named --executable to the build_scripts command to override that, directly on the command line, or in a configuration file: $ cat setup.cfg [build_scripts] executable = /usr/bin/python Regards merwok (distutils2 GSoC student for PSF :) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c21fd3e.5070...@netwok.org
Re: Python talks at DebConf
Hello The premise of your implication is false. Please translate to simple English. premise: something you base your reasoning on implication: something you present as true as a result of a reasoning In other words: Your argument says something that is based on an inexact thought. If I understand correctly, the implication is that people have to use complicated tools, and the premise is that stdeb is unusable. Hope this helps. Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf38f53.6010...@netwok.org
