Re: setup.py sdist permissions

Replied on the bug :) On 4 April 2018 at 20:04, Brian May wrote: > Yaroslav Halchenko writes: > >> just anecdotal support: my umask is 077 as well, have been doing uploads >> to pypi for a while, never had report from the users about any problem. >> The

Re: Thread on flit...

On 18 February 2018 at 00:03, Paul Wise wrote: > On Sat, Feb 17, 2018 at 4:41 PM, Julien Puydt wrote: > >> It is intended for trivial packaging... so perhaps dh_python could >> detect its use and do something smarter. > > Ideally, debhelper should DTRT no matter what build system

Re: New, updated pip coming

placed in > - the /usr/share/python-wheels directory. Such wheels must be built > - with the --universal flag so as to generate wheels > - compatible with both Python 2 and Python 3. > + When these binary packages are installed, .whl files must be placed > + in the /usr/share/python-wheels directory. The location inside a > + virtual environment will be rooted in the virtual environment, > + instead of in /usr. > > > > -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud

Re: Bug#802839: django-celery: python 3 tests not invoked and break

I'd probably shut that warning up using the warnings module API rather than weaking the test more broadly. Also - track down and file a bug on the leak source.

Re: Python < 3.5 tests

umably https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests would be the intent? The tarball on PyPI is missing it - so I think its a broken MANIFEST.in - it hasn't been updated to include the tests. So the error thats being reported is that ajax_select can't be imported - which mean

Re: Python < 3.5 tests

e importing anything from within it will need to initialise the package first, which is basic Python semantics. 800139 has the same issue. Any tests of these packages will need to import the package itself to exercise it, so I don't see a CPython/discover bug here. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud

Re: Python < 3.5 tests

On 8 October 2015 at 12:05, Ben Finney <ben+deb...@benfinney.id.au> wrote: > Robert Collins <robe...@robertcollins.net> writes: > >> On 8 October 2015 at 11:47, Ben Finney <ben+deb...@benfinney.id.au> wrote: >> > If you have a code base that is intended to ru

Re: Python < 3.5 tests

Probably the discover improvements in 3.5 try using python -m unittest2.discover On 8 Oct 2015 10:12, "Brian May" wrote: > Hello, > > When debugging #801208, I noticed the following output: > >dh_auto_test -O--buildsystem=pybuild >I: pybuild base:170: cd

Re: Python < 3.5 tests

hats false. unittest2 is a rolling backport. A true statement would be 'if your codebase will only ever run on the latest release of Python then unittest2 offers no value' for it. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

e more than 20 packages currently in Sid, even >>> though upstream (Robert Collins) is employed by HP and knew OpenStack >>> Kilo (currently in Sid) would break with his new changes. >> >> So much for the finger-pointing. Just to set things straight: Uploading >&g

Re: Application libraries private, Distutils metadata available for console scripts and introspection

ing, since if it is present but the package/module is not that is at the very best confusing for tools like pip. That private directory must be on the python search path when running the application (or the modules can't be imported). -Rob -- Robert Collins <rbtcoll...@hp.com> Distin

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 2 September 2015 at 22:45, Ben Finney <ben+deb...@benfinney.id.au> wrote: > Robert Collins <robe...@robertcollins.net> writes: > >> That private directory must be on the python search path when running >> the application (or the modules can't be imported). >

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 2 September 2015 at 21:19, Karsten Hilbert <karsten.hilb...@gmx.net> wrote: > On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote: > >> > Ben Finney <ben+deb...@benfinney.id.au> writes: >> >> > According to Robert's earlier message, tha

Re: Application libraries private, Distutils metadata available for console scripts and introspection

On 1 September 2015 at 17:35, Ben Finney <ben+deb...@benfinney.id.au> wrote: > Robert Collins <robe...@robertcollins.net> writes: > >> PKG resources should find it anywhere in the python path. > > That's exactly the point, though. The packages are private to

Re: Application libraries private, Distutils metadata available for console scripts and introspection

PKG resources should find it anywhere in the python path. I'd the path correct within the all processes? On 1 Sep 2015 2:53 pm, "Ben Finney" wrote: > Howdy all, > > How can I specify to Pybuild that an application should have its modules > all in a private namespace,

Re: Removing some python3-* packages

to patch upstream projects? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud

Re: Removing some python3-* packages

On 25 August 2015 at 11:49, Thomas Kluyver tho...@kluyver.me.uk wrote: On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote: c) write convoluted tricky code to workaround the bugs and differing behaviour on 3.4 vs 3.5. I use unittest.mock from Python 3.4 on several packages, and it has

Re: Removing some python3-* packages

On 25 August 2015 at 10:37, Barry Warsaw ba...@debian.org wrote: On Aug 25, 2015, at 10:03 AM, Robert Collins wrote: On 25 August 2015 at 09:57, Barry Warsaw ba...@debian.org wrote: ... By all means, if there isn't any significant difference between a standalone package and what's available

Re: Removing some python3-* packages

sense. I don't have a view on other packages. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https

Re: Removing some python3-* packages

to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock -Rob -- Robert Collins rbtcoll...@hp.com

Re: Removing some python3-* packages

for not-running-from-hg. Same for traceback2, linecache2, and shortly, when I get a day to fix it up, mock. All those IMO should remain packaged, because the stdlib is moving on them, and folk like being able to use the new shiny without waiting years. -Rob -- Robert Collins rbtcoll...@hp.com

Re: Removing some python3-* packages

’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. +1. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python

Re: Removing some python3-* packages

On 3 July 2015 at 15:05, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au

Re: /usr/bin/python in Python 2 and 3

). IMO Folks existing scripts should be left to use python, but encouraged to used python2 if they can't be changed to python3, and new scripts should just use python3. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python

Re: PyCon BoF: Stretch goals for cPython, PyPy CFFI

revisit it, but I've seen absolutely no good reason to push on this other than 'Gentoo did it' - scratch that, absolutely no good reason to push on it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ

Re: wheel support for Debian?

rationale for choosing the names I did. Whats the tiebreak logic for a package foo.wheels (e.g. if py.wheels comes along, will it be python-py-wheels-wheels for the wheels for it?) Did you consider using python-wheels-urllib3 ? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP

Re: Python 3.4 and ensurepip (rehashed, long)

surprised if a package manager told to upgrade itself used a different source for its own code vs things it manages. Yes, people that use pip to install things globally deserve to keep both pieces, but either prohibit it entirely, or have it work as advertised, not some frankenstein. -Rob -- Robert

Re: Indeed, python-concurrent.futures is the same

On 25 January 2014 23:01, Sandro Tosi mo...@debian.org wrote: Sorry, what? and you didn't think to contact me first to almost rewrite the package? If there's problems, open bugs. Revert your changes or I'll do at the first occasion. and mainly, why don't you go away from DPMT once and for all?

Re: Using update-alternatives for /usr/bin provided binaries

I think it's reasonable to get OpenStack to look for python-coverage to run it's tests when using a system package. Or use python -m coverage. 'coverage' is indeed super generic and the precedent within Debian for the package is to call the binary 'python-coverage'. Is there some reason we can't

Re: PEP 394 and shebang lines for /usr/bin/python2 scripts

is migrated - if ever. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- 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

Re: How does team maintenace of python module works?

- Migrate all the DPMT-maintained packages to git. DCA -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive

Re: [Openstack-devel] New version of python-fixtures for debian experimental

On 18 February 2013 17:03, Thomas Goirand z...@debian.org wrote: On 02/15/2013 03:23 PM, Robert Collins wrote: +1 on what you've done and what you propose. If you want to set Maintainer to DPMT and commit it to the DPMT svn repository at the same time, that would be awesome. Robert, Both

Re: How does team maintenace of python module works?

, and that contributors we get will be familiar with git, than any other system now. That doesn't mean git is better or worse, but if we're changing systems because of preference (rather than fitness-for-purpose), then I think we'd be crazy to consider any other VCS. -Rob -- Robert Collins rbtcoll...@hp.com

Re: New upstream release of python-testtools

also upload this package in the python module team SVN repository, instead of collab-maint BZR (since we agreed on it for python-fixtures, probably you would like this to be done as well for this package)? Yes please. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP

Re: Current state of packaging Python software for Debian

On Sat, Jul 2, 2011 at 2:07 AM, Barry Warsaw ba...@python.org wrote: In some sub-communities, py.test or nosetests are the standard, not setup.py test. Yes, but if I understand where Michael is taking unittest2, those can just be refactored to be plugins instead of separate standards.  Then

Re: Switching to git

On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman deb...@kitterman.com wrote: ... reasonably comfortable for both.  It's not as fast a git and it suffers from not being able to do partial checkouts (like git), so it's very much a middle ground in both advanatages and disadvantages between svn and

Re: Switching to git

On Mon, Mar 7, 2011 at 8:09 AM, Scott Kitterman deb...@kitterman.com wrote: Robert Collins robe...@robertcollins.net wrote: On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman deb...@kitterman.com wrote: ... reasonably comfortable for both.  It's not as fast a git and it suffers from not being

Re: coming back to packaging multiple versions of libraries

2011/1/6 Piotr Ożarowski pi...@debian.org: IMHO installing two versions of the same (public) Python module should be simply forbidden in policy. For one simple reason: if module foo uses bar in version 1 and spam uses bar in version 2, imagine what will happen with egg which uses both foo and

Re: coming back to packaging multiple versions of libraries

On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw ba...@python.org wrote: These are not necessarily mutually exclusive. ;) #3 and #4 are both worth pursuing in any case, but kind of outside the domain of either upstream (except were the stdlib is concerned) or debian-python.  Still, as a Python

Re: coming back to packaging multiple versions of libraries

On Thu, Jan 6, 2011 at 1:14 PM, Barry Warsaw ba...@python.org wrote: On Jan 06, 2011, at 12:45 PM, Robert Collins wrote: I'm not trying to do this in a hidden way though? Why do you think that that is the case? Sorry, I meant automatic. I'm not proposing anything magical: maintainer intent

Re: coming back to packaging multiple versions of libraries

On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski pi...@debian.org wrote: what's the point of installing two different versions of the same module if only one will be used anyway? If the answer to that question is: in the application where I need different version, I will adjust sys.path - why

coming back to packaging multiple versions of libraries

So in the thread 'Python packaging, dependencies, upstream facilities' we had a brief talk that faded out; rather than resurrecting the entire thread, I'd like to pick one point that seems like a necessary condition to me: installing the eggs in versioned paths rather than simple module paths.