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
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
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
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
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:
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
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
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
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?
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
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
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
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
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
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
- 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?
--
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
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
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
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
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
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
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
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.
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!
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
26 matches
Mail list logo
