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
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
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
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.
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
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
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
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
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
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
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
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).
>
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
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
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,
to patch upstream projects?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
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
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
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
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
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
’ 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
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
).
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
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
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
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
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?
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
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
- 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
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
, 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
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
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
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
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
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
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
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
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
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.
42 matches
Mail list logo