delta/python-setuptools-git.git, branch v41.0.1 github.com: pypa/setuptools.git Bump version: 41.0.0 → 41.0.1 2019-04-22T20:07:03+00:00 Benoit Pierre benoit.pierre@gmail.com 2019-04-22T20:07:03+00:00 97d7563915b6e2ad8a638e988361357709a83bda 






travis: re-enable coverage for Python 3.8 job (#1748)
2019-04-22T16:00:24+00:00

Benoit Pierre
benoit.pierre@gmail.com

2019-04-22T16:00:24+00:00

e66857af348a823b15701c39a88add28cfaab3bd

Now that the issue with invalid coverage data has been fixed.




Now that the issue with invalid coverage data has been fixed.






Merge pull request #1745 from shashanksingh28/master
2019-04-22T15:52:09+00:00

Paul Ganssle
pganssle@users.noreply.github.com

2019-04-22T15:52:09+00:00

50a41c7005c81024cf66fcd1d940fd168dc4a83d

Fix error with PEP 517 builds when wheel exists (GH #1761)




Fix error with PEP 517 builds when wheel exists (GH #1761)






Merge pull request #1747 from pganssle/limit_workers
2019-04-22T15:45:08+00:00

Paul Ganssle
pganssle@users.noreply.github.com

2019-04-22T15:45:08+00:00

2b5accfaa4cfe4a3638dedabce13a4991d955179

Limit workers in ProcessPoolExecutor




Limit workers in ProcessPoolExecutor






Limit workers in ProcessPoolExecutor
2019-04-22T15:17:21+00:00

Paul Ganssle
paul@ganssle.io

2019-04-22T15:05:29+00:00

127c8c74dead715b67a66eed86c420fe7b31ea3b

As a mitigation for #1730, this commit limits the number of workers in
the ProcessPoolExecutor to 1 (default is the number of CPUs). On PyPy,
having a higher number of available workers dramatically increases the
number of concurrent processes, leading to some resource exhaustion
issues.

This does not address the root issue, but should improve the situation
until the root issue is addressed.





As a mitigation for #1730, this commit limits the number of workers in
the ProcessPoolExecutor to 1 (default is the number of CPUs). On PyPy,
having a higher number of available workers dramatically increases the
number of concurrent processes, leading to some resource exhaustion
issues.

This does not address the root issue, but should improve the situation
until the root issue is addressed.







Merge pull request #1746 from benoit-pierre/swith_travis_dist_to_xenial
2019-04-22T15:15:24+00:00

Paul Ganssle
pganssle@users.noreply.github.com

2019-04-22T15:15:24+00:00

dd2240a7404a39f2f6d446697d871ba0c22be17a

Use xenial and latest pypy3 on Travis CI.




Use xenial and latest pypy3 on Travis CI.






travis: update PyPy 3 job to latest supported version
2019-04-22T14:54:42+00:00

Benoit Pierre
benoit.pierre@gmail.com

2019-04-22T14:53:37+00:00

3a797435ccdc5a115b681572d5ba0cfd484ae810












travis: preemptively switch to xenial
2019-04-22T14:49:46+00:00

Benoit Pierre
benoit.pierre@gmail.com

2019-04-22T14:49:46+00:00

bd3d72b030eeae19ebc2eb3a0a325f87b41a09f1

As it will soon become the default: https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment





As it will soon become the default: https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment







Add changelog for PR #1745
2019-04-22T14:19:28+00:00

Shashank Singh
shashanksingh28@gmail.com

2019-04-21T03:25:59+00:00

e4f987b141104e709367cbe629f3cd6ef5153216












Fix error when wheels already exist in dist/
2019-04-22T14:19:28+00:00

Shashank Singh
shashanksingh28@gmail.com

2019-04-21T03:24:41+00:00

901f7cc2a036bfeb93bfbe480608e04c76c2c5ec

`build_meta.build_wheel` assumes that the only wheel in its output
directory is the one it builds, but prior to this, it also used the
`dist/` folder as its working output directory. This commit uses a
temporary directory instead, preventing an error that was triggered when
previously-generated wheel files were still sitting in `dist/`.

Fixes GH #1671





`build_meta.build_wheel` assumes that the only wheel in its output
directory is the one it builds, but prior to this, it also used the
`dist/` folder as its working output directory. This commit uses a
temporary directory instead, preventing an error that was triggered when
previously-generated wheel files were still sitting in `dist/`.

Fixes GH #1671