On Wed, Oct 7, 2015 at 3:39 PM, Robert Collins
wrote:
[...]
> Its all about easy-install. This is why I put a proof of concept
> static-setup-requires thing together for pip (and its on our teams
> roadmap to deliver a production version of it via patches to all the
> pypa projects, we're just not
On 8 October 2015 at 04:32, Erik Bray wrote:
> Starting a sub-thread since issues with pbr are orthogonal to the
> original disucssion.
>
> But one point I'd like to raise about this is that when I originally
> designed d2to1, on which a chunk of pbr is based, it was *explicitly*
> designed to nev
On 7 October 2015 at 22:53, Nathaniel Smith wrote:
>> I think I'm as confused by what you're saying here as Donald is. Could
>> you give a few examples of such projects? I'd like to go & take a look
>> at them and try to understand what they are doing that is so
>> incompatible with what Donald an
On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > Yeah, that's not a good long term solution -- it needs to be moved
> into the metadata (probably by creating an MKL wheel and then
> making
> the numpy wheel depend on it). That's exactly the problem :-)
>
Are you
On Wed, Oct 7, 2015 at 11:14 AM, Paul Moore wrote:
> On 7 October 2015 at 18:27, Nathaniel Smith wrote:
>> There are projects on PyPI right now, today, that have no way to
>> generate sdists and will never have any need for "source wheels"
>
> I think I'm as confused by what you're saying here as
On 7 October 2015 at 22:28, Nathaniel Smith wrote:
> Maybe I have misunderstood: does it actually help pip at all to have
> static access to name and version, but not to anything else? I've been
> assuming not, but I don't think anyone's pointed to any examples yet
> of the problems that pip is en
On Wed, Oct 7, 2015 at 1:28 PM, Paul Moore wrote:
> The disconnect here seems to be that I view all of those wheels as
> being numpy 1.9.X wheels (or whatever). They differ in terms of
> compatibility details, but they are all wheels for the same
> project/version. So there's no problem with them
On Wed, Oct 7, 2015 at 4:42 PM, Ionel Cristian Mărieș
wrote:
> On Wed, Oct 7, 2015 at 3:18 PM, Donald Stufft wrote:
>
>> tox and setup.py test are not really equivalent. There’s no way (to my
>> knowledge) to test the item outside of a virtual environment. This is
>> important for downstreams wh
On 7 October 2015 at 20:36, Oscar Benjamin wrote:
> Currently I can take the code from the numpy release and compile it in
> different incompatible ways. For example I could make a wheel that bundles a
> BLAS library. Or I could make a wheel that expects to use a system BLAS
> library that should
On Wed, 7 Oct 2015 19:42 Donald Stufft wrote:
On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benja...@gmail.com)
wrote:
> >
> Your idea of an sdist as something that has fully static build/runtime
> dependency metadata and a one to one correspondence with binary
> wheels is not a usabl
On Oct 07, 2015, at 09:46 AM, Ben Finney wrote:
>So “I'm a big fan of putting tests inside the [Python] package
>[directory]” can't be motivated by “Having the tests there in the
>installed package”. The two aren't related, AFAICT.
It makes it easier for sure. When the tests are inside the packa
On Oct 07, 2015, at 08:35 AM, Marius Gedminas wrote:
>I have hopes for 'tox.ini' becoming the standard way to test a Python
>project.
As do I, modulo outliers of course. I'd like to see 90% of PyPI packages have
a tox.ini.
Cheers,
-Barry
pgpxJ0ovIWbuL.pgp
Description: OpenPGP digital signatur
On Oct 07, 2015, at 08:18 AM, Donald Stufft wrote:
>tox and setup.py test are not really equivalent. There’s no way (to my
>knowledge) to test the item outside of a virtual environment. This is
>important for downstreams who want to test that the package build and the
>tests successfully are execu
On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benja...@gmail.com)
wrote:
> >
> Your idea of an sdist as something that has fully static build/runtime
> dependency metadata and a one to one correspondence with binary
> wheels is not a usable format when releasing the code for e.g.
>
On Wed, 7 Oct 2015 18:51 Donald Stufft wrote:
On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (n...@pobox.com) wrote:
> On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote:
> [...]
> > I also don't think it will be confusing. They'll associate the VCS
thing (a source release)
> as something fo
On October 7, 2015 at 11:32:32 AM, Erik Bray (erik.m.b...@gmail.com) wrote:
> > I don't know what features pbr has grown that might make someone
> want
> it to be a runtime dependency (the only entry-points I noticed
> were
> for adding egg-info writers but that should only be needed at
> bui
On 7 October 2015 at 18:27, Nathaniel Smith wrote:
> There are projects on PyPI right now, today, that have no way to
> generate sdists and will never have any need for "source wheels"
I think I'm as confused by what you're saying here as Donald is. Could
you give a few examples of such projects?
On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (n...@pobox.com) wrote:
> On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote:
> [...]
> > I also don't think it will be confusing. They'll associate the VCS thing (a
> > source release)
> as something focused on development for most everyone. Mo
On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote:
[...]
> I also don't think it will be confusing. They'll associate the VCS thing (a
> source release) as something focused on development for most everyone. Most
> people won't explicitly make one and nobody will be uploading it to PyPI. The
On Wed, Oct 7, 2015 at 6:37 PM, Erik Bray wrote:
> Which, incidentally, is a great reason for installable tests :)
>
Not really. Doesn't matter where you have the tests. It matters where you
have the code being tested.
Tests being installed is a mere consequence of the location of tests.
>
On Wed, Oct 7, 2015 at 11:31 AM, Ionel Cristian Mărieș
wrote:
>
> On Wed, Oct 7, 2015 at 6:13 PM, Erik Bray wrote:
>>
>> > Lets not use `setup.py test`. It's either bad or useless.
>>
>> Says who? Many of the projects I'm involved in use `setup.py test`
>> exclusively and for good reason--they a
On Wed, Oct 7, 2015 at 6:13 PM, Erik Bray wrote:
> > Lets not use `setup.py test`. It's either bad or useless.
>
> Says who? Many of the projects I'm involved in use `setup.py test`
> exclusively and for good reason--they all have C and/or Cython
> extension modules that need to be built for the
On Tue, Oct 6, 2015 at 7:46 PM, Ionel Cristian Mărieș
wrote:
>
> On Wed, Oct 7, 2015 at 2:23 AM, Robert Collins
> wrote:
>>
>>
>> Hangon, there's clearly a *huge* gap in understanding here.
>>
>> pbr does *not* modify *anyones* setup.py output unless its enabled.
>
>
> Unless it's >=1.7.0. You ca
On Tue, Oct 6, 2015 at 6:08 PM, Ionel Cristian Mărieș
wrote:
>
> On Wed, Oct 7, 2015 at 12:51 AM, Ben Finney
> wrote:
>>
>> I think the above describes the standard way of declaring the test
>> runner: The ‘setup.py test’ command.
>>
>> Now, I lament that more Python projects don't *conform to* t
On Wed, Oct 7, 2015 at 3:20 PM, Wes Turner wrote:
> > 2. The "test" command will install the "test_requires" dependencies as
> eggs. You will end up with multiple versions of the same eggs right in your
> source checkout.
>
> * is there no way around this?
> * is this required / spec'd / fixable?
On Wed, Oct 7, 2015 at 3:18 PM, Donald Stufft wrote:
> tox and setup.py test are not really equivalent. There’s no way (to my
> knowledge) to test the item outside of a virtual environment. This is
> important for downstreams who want to test that the package build and the
> tests successfully ar
On Oct 7, 2015 6:58 AM, "Ionel Cristian Mărieș" wrote:
>
>
> On Wed, Oct 7, 2015 at 8:12 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
>>
>> I thought "easy_install" is a very old and deprecated method.
>
>
> Indeed it is. That why people put all sorts of custom "test" commands in
the
On October 7, 2015 at 7:58:55 AM, Ionel Cristian Mărieș (cont...@ionelmc.ro)
wrote:
> On Wed, Oct 7, 2015 at 8:12 AM, Thomas Güttler > > wrote:
> > Why not use `setup.py test`?
> >
>
> Because:
>
> 1. There's Tox, which does exactly that, and more. It's maintained. It
> gets features.
tox a
On Wed, Oct 7, 2015 at 8:12 AM, Thomas Güttler wrote:
> I thought "easy_install" is a very old and deprecated method.
>
Indeed it is. That why people put all sorts of custom "test" commands in
their setup.py to work around the deficiencies of the "test
" command setuptools provides. So we en
On Oct 7, 2015 12:44 AM, "Marius Gedminas" wrote:
>
> On Tue, Oct 06, 2015 at 05:21:27PM -0400, Barry Warsaw wrote:
> > On Oct 06, 2015, at 06:21 AM, Donald Stufft wrote:
> >
> > >FreeBSD relies on ``python setup.py test`` as it's preferred test
invocation,
> > >so it apparently doesn't find it us
30 matches
Mail list logo
