The pex 1.6.4 release is out: + https://pypi.org/project/pex/1.6.4/#files + https://github.com/pantsbuild/pex/releases/tag/v1.6.4

so... what else do folks want in `1.15.0`final? twitter has been running

1.15.0rc1

for a few days now without issue

What causes contrib packages to die? I saw we used to have a Haskell contrib release?!

The pex 1.6.5 release is out: + https://pypi.org/project/pex/1.6.5/#files + https://github.com/pantsbuild/pex/releases/tag/v1.6.5

The pex 1.6.6 release is out: + https://pypi.org/project/pex/1.6.6/#files + https://github.com/pantsbuild/pex/releases/tag/v1.6.6

well, dang. i believe that the docker image change has broken

1.15.x

ci. i will not be investigating that tonight... but i'm hoping that cherry-picking ... some

.travis.yml

change ... will fix it?

Oof did not think about that one… cherry-picking this should fix it all! https://github.com/pantsbuild/pants/pull/7064

You don’t need to cherry-pick the followup to simplify the

travis_docker

image (https://github.com/pantsbuild/pants/pull/7505), only #7064

@enough-analyst-54434: regarding: https://github.com/pantsbuild/pants/blob/805d36e4df797f2405604feca10df9148f74244d/contrib/python/src/python/pants/contrib/python/checks/tasks/checkstyle/checkstyle.py#L155-L158 ... what is a valid reason for that to happen?

Yi missed last week, and John is out, so i'll prep 1.16.0.dev1 today.

will continue that discussion in #pex

@witty-crayon-22786 should we release 1.15.1 with this https://github.com/pantsbuild/pants/pull/7556. Without it,

./pants markdown

and

./pants rst

will render byte literal at top of any generated file

yea, might be worth picking. not worth blocking on though, i don't think.

@hundreds-father-404: so, nothing blocking announcing 1.15.0, right?

ah, according to #python3, we're good to go. announcing.

it looks like a recent change broke the

Deploy pants pex unstable

shards on master

Hey all (cc @aloof-angle-91616), how soon are we comfortable starting release candidates for 1.16.x? Our timeline got off a bit with the delayed 1.16.0.dev1. Hoping we can cut it sooner than the cadence we used 1.15.x so that we can get to 1.17.x sooner

we can cut it right now

how is the perf looking?

our internal release script has an error now which is what's blocking us from being more comfortable

I’d like to fix https://github.com/pantsbuild/pants/issues/7510 first (interpreter constraints caching). Can reshuffle schedule to do that this week

@hundreds-father-404 is anyone else on the osx wheel building error right now cause i can pick that up

@aloof-angle-91616 for 1.16.x, everything I wanted is now included. Once we fix PEX release, would be great for this to be the last dev release so that next week we can start 1.16.0rc0 and then 1.17.0.dev0

Master is now green again, thanks to John’s fix :) @aloof-angle-91616 once we decide on forking pantsd, hopefully we’re on track for 1.16.0rc0 this week

...and Eric's save. 1.16.0.dev2 release prep: https://github.com/pantsbuild/pants/pull/7603

we are working to get pantsd fork removal in 1.16.0rc0, will revise if that seems infeasible

@hundreds-father-404 when i install pants via the setup instructions at https://www.pantsbuild.org/install.html, everything works great. however, when i run

./pants generate-pants-ini

, i see pants bootstrapping the venv, resulting in:

New virtual environment successfully created at /home/cosmicexplorer/.cache/pants/setup/bootstrap-Linux-x86_64/unspecified_py36.
Adding sensible defaults to /home/cosmicexplorer/projects/active/funnel/pants.ini:
* Pinning `pants_version` to `1.15.0`.

You may modify these values directly in the file at any time. The ./pants script will detect any changes the next time you run it.

You are now ready to use Pants!

after that, when i run

./pants -V

, pants actually bootstraps again from scratch (although it's faster the second time), ending with:

New virtual environment successfully created at /home/cosmicexplorer/.cache/pants/setup/bootstrap-Linux-x86_64/1.15.0_py36.
1.15.0

the difference between the two runs seems to be when it creates the venv in

.../unspecified_py36

vs

.../1.15.0_py36

. is this double bootstrapping a known issue with the setup script? can it be avoided?

Known and can't be avoided without turning generate-pants-ini into shell code in the pants script. Eric initially went this route and I dissuaded him without forseeing this consequence 😕