Yah, packaging permissions are an installation problem, and setup.py
is (no longer) intended for installation.
-Rob
On 5 April 2018 at 10:25, Brian May wrote:
> Robert Collins writes:
>
>> Replied on the bug :)
>
> Thanks.
>
> He responded, he is not using pip, but
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 reasons could be either it indeed doesn't
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 is in use.
Agree
and the
> -whl
> - suffix, e.g. python-chardet-whl. When these
> - binary packages are installed, their .whl files must be 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
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.
On 9 October 2015 at 10:40, Brian May wrote:
> On Fri, 9 Oct 2015 at 08:16 Robert Collins
> wrote:
>>
>> But - ajax_select/__init__.py is going to be imported, and thats whats
>> erroring. I don't think that this is a 3.5 unit testing change - I
>> think its an
nned, because
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
Distinguished Technologist
HP Converged Cloud
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 means that ajax_select/__init__.py can't be imported.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
On 8 October 2015 at 12:05, Ben Finney wrote:
> Robert Collins writes:
>
>> On 8 October 2015 at 11:47, Ben Finney wrote:
>> > If you have a code base that is intended to run unchanged on Python
>> > 2 and Python 3, and that code base imports ‘unittest2’, you n
On 8 October 2015 at 11:26, Brian May wrote:
> On Thu, 8 Oct 2015 at 08:18 Robert Collins
> wrote:
>>
>> Probably the discover improvements in 3.5 try using python -m
>> unittest2.discover
>
>
> Just trying that now.
>
> I see that there is a python3-uni
7;if your codebase will only ever run on the latest release of
Python then unittest2 offers no value' for it.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
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 /«PKGBUILDDIR»/.pybuild/pythonX.Y_
ages 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
>> mock-1.3 to unsta
On 2 September 2015 at 21:19, Karsten Hilbert wrote:
> On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote:
>
>> > Ben Finney writes:
>>
>> > According to Robert's earlier message, that means the Distutils
>> > metadata file needs to b
On 2 September 2015 at 22:45, Ben Finney wrote:
> Robert Collins writes:
>
>> That private directory must be on the python search path when running
>> the application (or the modules can't be imported).
>
> Not at all. The application's private modules are im
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
Distinguished Technologist
HP Converged Cloud
On 1 September 2015 at 17:35, Ben Finney wrote:
> Robert Collins writes:
>
>> PKG resources should find it anywhere in the python path.
>
> That's exactly the point, though. The packages are private to this
> application, and should not be available for import by othe
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, but have the Distutils metada
On 25 August 2015 at 11:49, Thomas Kluyver 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
On 25 August 2015 at 11:23, Barry Warsaw wrote:
> On Aug 25, 2015, at 10:45 AM, Robert Collins wrote:
>
>>Lets take Ironic. While it supports Python 2.7+ and 3.4+ it will
>>depend on 'mock' for unit testing.
>
> That's not unreasonable, and different upstre
On 25 August 2015 at 10:37, Barry Warsaw wrote:
> On Aug 25, 2015, at 10:03 AM, Robert Collins wrote:
>
>>On 25 August 2015 at 09:57, Barry Warsaw wrote:
>>...
>>> By all means, if there isn't any
>>> significant difference between a standalone packag
the cost of having to patch upstream projects?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
I don't have a view on other packages.
-Rob
--
Robert Collins
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://lis
On 3 July 2015 at 15:05, Ian Cordasco wrote:
> On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins
> wrote:
>> On 3 July 2015 at 11:44, Ian Cordasco wrote:
>>> On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney
>>> wrote:
>>>> Barry Warsaw writes:
>>&
ss you're planning on supporting
> packages for python 3.3 as well that will generate a numerous amount
> of bugs for you.
See my prior mail. I will be backporting all the changes in mock from
the stdlib to the mock standalone lib in the near future.
I have upload acls from Michael Fo
e new features for 3.5 as well.
> So I'd argue that ‘python3-mock’ 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
Distinguished Technologis
those examples are already packaged for Py3)
So, unittest2 is *explicitly* targeted at 3.5, 3.4, 3.3, 3.2, 2.7,
2.6. Its not 'unittest for 2.6', its unittest for not-running-from-hg.
Same for traceback2, linecache2, and shortly, when I get a day to fix
it up, mock.
All those IMO sho
#x27;t a problem anymore.
This still seems like a profoundly poor idea: 'is X python3
compatible' is a turing completeness problem. There are some scripts
where you can determine compatibility, but many where you cannot until
it blows up (particularly ones with subtle bugs in string type
If you want
> python3, then the interpreter you're looking for is found at /usr/bin/python3.
>
> There's no dilemma to solve.
I agree.
Maybe in 2029 we can revisit it, but I've seen absolutely no good
reason to push on this other than 'Gentoo did it' - scratch
re
> git tree, have a suspicion that might get complicated however...
Whats the actual upstream, and what do you want users to have
available in terms of Debian packages?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
--
To UNSUBSCRIBE, email to debian-python-requ
hat the latter would be called python-urllib3-wheels.
>
> It's bikeshedding, but anyway that was my 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
rtunate that it upgraded itself from an external source.
I'd be very 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 entirel
On 25 January 2014 23:01, Sandro Tosi 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? you're doing
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 t
local unpackaged Python2 scripts
It may be some time *after* Python2.x is gone from the archive that
all that legacy debt is migrated - if ever.
-Rob
--
Robert Collins
Distinguished Technologist
HP Cloud Services
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.
or git, so new packages
> can be committed to git if the packager prefers. Optionally, we could make
> provisions to migrate existing packages.
> D - Migrate all the DPMT-maintained packages to git.
DCA
-Rob
--
Robert Collins
Distinguished Technologist
HP Cloud Services
--
On 18 February 2013 17:03, Thomas Goirand 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 awe
date&hlght_date&date_fmt=%25Y-%25m&beenhere=1
If we're changing VCS, there is a vastly higher probability that the
folk whose software we are packaging is in git, and that contributors
we get will be familiar with git, than any other system now. That
doesn't mean git is better
thank you.
> Can I 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
Distinguished Techn
On Sat, Jul 2, 2011 at 2:07 AM, Barry Warsaw 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 `python setup
On Mon, Mar 7, 2011 at 8:09 AM, Scott Kitterman wrote:
> Robert Collins wrote:
>
>>On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman
>>wrote:
>>...
>>> reasonably comfortable for both. It's not as fast a git and it
>>suffers from
>>> not b
On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman 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 git.
I believe t
On Thu, Jan 6, 2011 at 1:14 PM, Barry Warsaw 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 propos
On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw 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
> programmer, if
2011/1/6 Piotr Ożarowski :
> 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 spam.
This i
On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski 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 not simply p
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.
Tak
On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
>Here there are two cases. Either module foo can't be written at all
>for version 2.6, or it the same functionality can be provided with
This is a little simplistic.
The parser changes fairly routinely in python versions. This me
48 matches
Mail list logo
