Re: [pytest-dev] Help testing 3.2.0 release (part 2)

2017-07-31 Thread Bruno Oliveira
On Mon, Jul 31, 2017 at 10:40 AM Florian Schulze 
wrote:

> > I had to do:
> >
> > pip install --no-cache-dir -U
> >
> https://devpi.net/nicoddemus/dev/+f/e50/b5a054e0007ca/pytest-3.2.0-py2.py3-none-any.whl
>
> This works with devpi tests as well.
>

Thanks Florian!

Cheers,
Bruno
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] Help testing 3.2.0 release (part 2)

2017-07-31 Thread Florian Schulze

I had to do:

pip install --no-cache-dir -U 
https://devpi.net/nicoddemus/dev/+f/e50/b5a054e0007ca/pytest-3.2.0-py2.py3-none-any.whl


This works with devpi tests as well.

Regards,
Florian Schulze
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] Doing pre-releases (was: Re: Help testing 3.2.0 release (part 2))

2017-07-31 Thread Ronny Pfannschmidt
we should mirror borgbackup in that regard

https://borgbackup.readthedocs.io/en/stable/changes.html#changelog
materializes releases candidates

we can do a automation around that as well

i wanted to propose adding a travis deploy that uploads release proposals
with materialized changelogs anyway
so that doing a release would be as simple as doing a merge form the ui

2017-07-31 14:03 GMT+02:00 Florian Bruhin :

> On Mon, Jul 31, 2017 at 11:59:32AM +, Bruno Oliveira wrote:
> > > (btw - I feel like everyone's life would be easier if we'd just push
> > > release canditates to PyPI which are installable with --pre. Then we
> can
> > > also simply do an rc2 in cases like this)
> > >
> >
> > Hmmm that does sound like a good idea at first. Two things came to my
> mind
> > though:
> >
> > 1. Doesn't tox install dependencies with --pre? If that's true then tox
> > users would install the release candidate by default.
>
> Not by default, only when you tell it to:
> http://tox.readthedocs.io/en/latest/config.html#confval-
> pip_pre=True%7CFalse(default)
> 
>
> > 2. Our release process doesn't account for it today, so we would have to
> > review it (specially changelog wise I think).
>
> What would change about changelogs? You could still just finalize the
> changelog with the final release, I think.
>
> Florian
>
> --
> https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
>  I love long mails!  | https://email.is-not-s.ms/
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


[pytest-dev] Doing pre-releases (was: Re: Help testing 3.2.0 release (part 2))

2017-07-31 Thread Florian Bruhin
On Mon, Jul 31, 2017 at 11:59:32AM +, Bruno Oliveira wrote:
> > (btw - I feel like everyone's life would be easier if we'd just push
> > release canditates to PyPI which are installable with --pre. Then we can
> > also simply do an rc2 in cases like this)
> >
> 
> Hmmm that does sound like a good idea at first. Two things came to my mind
> though:
> 
> 1. Doesn't tox install dependencies with --pre? If that's true then tox
> users would install the release candidate by default.

Not by default, only when you tell it to:
http://tox.readthedocs.io/en/latest/config.html#confval-pip_pre=True%7CFalse(default)

> 2. Our release process doesn't account for it today, so we would have to
> review it (specially changelog wise I think).

What would change about changelogs? You could still just finalize the
changelog with the final release, I think.

Florian

-- 
https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
 I love long mails!  | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] Help testing 3.2.0 release (part 2)

2017-07-31 Thread Bruno Oliveira
On Mon, Jul 31, 2017 at 8:44 AM Florian Bruhin  wrote:

> Thanks! Seems to work fine with qutebrowser this time :)
>

Glad to know, thanks!

>
> > The package is available at:
> >
> > https://devpi.net/nicoddemus/dev/pytest/3.2.0
> >
> > And can be installed with:
> >
> > pip install -U
> >
> https://devpi.net/nicoddemus/dev/+f/aeb/edee851da9e58/pytest-3.2.0-py2.py3-none-any.whl
>
> I had to do:
>
> pip install --no-cache-dir -U
> https://devpi.net/nicoddemus/dev/+f/e50/b5a054e0007ca/pytest-3.2.0-py2.py3-none-any.whl
>
> It looks like the URL changed when you re-uploaded it, and I had to use
> --no-cache-dir to convince pip to re-download it.
>

Oops yep my bad, I shamelessly copied my previous email and just edited it
a bit. :P

(btw - I feel like everyone's life would be easier if we'd just push
> release canditates to PyPI which are installable with --pre. Then we can
> also simply do an rc2 in cases like this)
>

Hmmm that does sound like a good idea at first. Two things came to my mind
though:

1. Doesn't tox install dependencies with --pre? If that's true then tox
users would install the release candidate by default.
2. Our release process doesn't account for it today, so we would have to
review it (specially changelog wise I think).

Thanks again for testing it out!

Cheers.
Bruno


> Florian
>
> --
> https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
>  I love long mails!  | https://email.is-not-s.ms/
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


Re: [pytest-dev] Help testing 3.2.0 release (part 2)

2017-07-31 Thread Florian Bruhin
Hey Bruno,

On Mon, Jul 31, 2017 at 11:31:12AM +, Bruno Oliveira wrote:
> I have prepared another package for the 3.2.0 release and again it would be
> great if people could help test it.

Thanks! Seems to work fine with qutebrowser this time :)

> The package is available at:
> 
> https://devpi.net/nicoddemus/dev/pytest/3.2.0
> 
> And can be installed with:
> 
> pip install -U
> https://devpi.net/nicoddemus/dev/+f/aeb/edee851da9e58/pytest-3.2.0-py2.py3-none-any.whl

I had to do:

pip install --no-cache-dir -U 
https://devpi.net/nicoddemus/dev/+f/e50/b5a054e0007ca/pytest-3.2.0-py2.py3-none-any.whl

It looks like the URL changed when you re-uploaded it, and I had to use
--no-cache-dir to convince pip to re-download it.

(btw - I feel like everyone's life would be easier if we'd just push
release canditates to PyPI which are installable with --pre. Then we can
also simply do an rc2 in cases like this)

Florian

-- 
https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
 I love long mails!  | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev


[pytest-dev] Help testing 3.2.0 release (part 2)

2017-07-31 Thread Bruno Oliveira
Hi everyone,

I have prepared another package for the 3.2.0 release and again it would be
great if people could help test it.

The package is available at:

https://devpi.net/nicoddemus/dev/pytest/3.2.0

And can be installed with:

pip install -U
https://devpi.net/nicoddemus/dev/+f/aeb/edee851da9e58/pytest-3.2.0-py2.py3-none-any.whl

If we don't encounter any blocking issue like last time I pretend to
release this tomorrow to PyPI. :)

Cheers,
Bruno.
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev