New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip 19.0 fails to install packages that import to-be-installed package from CWD #6163

Closed
jeanlaroche opened this Issue Jan 22, 2019 · 87 comments

Comments

Projects
None yet
@jeanlaroche
Copy link

jeanlaroche commented Jan 22, 2019

Environment

  • pip version: 19.0
  • Python version: 3.6
  • OS: MacOS

Description
When running pip install pyinstaller==3.4 with pip 19.0 we are getting an install error. ModuleNotFoundError: No module named 'PyInstaller'

Expected behavior
Expect pyinstall to be installed, as it is with pip 18.1

How to Reproduce
Using python3:
pip install pyinstaller=3.4

Output

pip install pyinstaller==3.4
Collecting pip
  Using cached https://files.pythonhosted.org/packages/60/64/73b729587b6b0d13e690a7c3acd2231ee561e8dd28a58ae1b0409a5a2b20/pip-19.0-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 9.0.3
    Uninstalling pip-9.0.3:
      Successfully uninstalled pip-9.0.3
Successfully installed pip-19.0
(BuildVEnv) jlaroche-mbp:TrackSense$ pip install pyinstaller
Collecting pyinstaller
  Using cached https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/jlaroche/Dev/uapkg/packages/system/algo/BuildVEnv/bin/python3 /Users/jlaroche/Dev/uapkg/packages/system/algo/BuildVEnv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/j6/7t8sg1vj4q97zhh9z5cdmxbm4rz935/T/tmps3z6flnv:
  Traceback (most recent call last):
    File "/Users/jlaroche/Dev/uapkg/packages/system/algo/BuildVEnv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/jlaroche/Dev/uapkg/packages/system/algo/BuildVEnv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/jlaroche/Dev/uapkg/packages/system/algo/BuildVEnv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/j6/7t8sg1vj4q97zhh9z5cdmxbm4rz935/T/pip-build-env-lo_ir5_f/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/j6/7t8sg1vj4q97zhh9z5cdmxbm4rz935/T/pip-build-env-lo_ir5_f/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/j6/7t8sg1vj4q97zhh9z5cdmxbm4rz935/T/pip-build-env-lo_ir5_f/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 20, in <module>
      from PyInstaller import __version__ as version, HOMEPATH, PLATFORM
  ModuleNotFoundError: No module named 'PyInstaller'

Maintainer note on timeline: See #6163 (comment)

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Jan 23, 2019

This seems to be an issue with either how pyinstaller is importing itself for installation.

It might be a good idea to file an issue over at the PyInstaller folks.

@rt121212121

This comment has been minimized.

Copy link

rt121212121 commented Jan 23, 2019

We currently use 18.1, and upgrading to 19.0 causes this problem for us as well. There is a related issue on the PyInstaller repo, where it is because pip '' is not in sys.path.

pyinstaller/pyinstaller#2730

@lithammer

This comment has been minimized.

Copy link

lithammer commented Jan 23, 2019

I think this is a pretty common workflow. You put __version__ = "1.2.3" in foo/__init__.py and then do import foo in setup.py so that you don't have to specify the version in two places. And any user of the the library can inspect the version according to PEP 396.

# foo/__init__.py
__version__ = "1.2.3"
# setup.py
from setuptools import setup

import foo

setup(..., version=foo.__version__)
@lithammer

This comment has been minimized.

Copy link

lithammer commented Jan 23, 2019

Also, this only happens if you have a pyproject.toml file (and setup.py). Remove it and the installation works fine. So there seems to be some differences in behaviour there. Maybe the traditional way modifies sys.path/PYTHONPATH?

@lithammer

This comment has been minimized.

Copy link

lithammer commented Jan 23, 2019

Ah, I think I get what is happening. Since by using a pyproject.toml file, you're basically telling pip you want to use PEP 517/518.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]

The above tells pip that it needs setuptools and wheel to build PyInstaller. But in the case of PyInstaller, it's also got this in its setup.py:

# setup.py
from PyInstaller import __version__

From a PEP 517 perspective, aside from setuptools and wheel, it means it needs itself to build. Which is of course a bit weird.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "PyInstaller"]
@dstufft

This comment has been minimized.

Copy link
Member

dstufft commented Jan 23, 2019

As @cjerdonek mentioned in #6175 (comment), could someone please check if --no-use-pep517 fixes this for them?

I suspect the cause of this issue is that build isolation or the PEP 517 code isn't making sure that the root of the package directory is on the sys.path, because pandas has a versioneer.py sitting next to setup.py. I recall this coming up at some point, but I don't remember off the top of my head what that discussion was. This might be considered an issue with the setuptools build backend instead of pip, or it might be the fault of pip's isolation mechanism.

@lithammer

This comment has been minimized.

Copy link

lithammer commented Jan 23, 2019

[...] could someone please check if --no-use-pep517 fixes this for them?

PyInstaller installs fine with --no-use-pep517.

@dstufft

This comment has been minimized.

Copy link
Member

dstufft commented Jan 23, 2019

Ok, then that's certainly an issue with the new PEP 517 code and I'm pretty sure the issue is just that the directory containing the project root hasn't been added to sys.path. Maybe @pfmoore will have a better sense of if that should be pip's responsbility or setuptools.

@ashb

This comment has been minimized.

Copy link

ashb commented Jan 23, 2019

If it helps another example of this (via apache-airflow is pip install pendulum==1.4.4 fails, but pip install --no-use-pep517 pendulum==1.4.4 works.

The stack trace we get is similar:

Collecting pendulum==1.4.4
  Using cached https://files.pythonhosted.org/packages/85/a5/9fc15751f9725923b170ad37d6c61031fc9e941bafd5288ca6ee51233284/pendulum-1.4.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/ash/.virtualenvs/clean-airflow/bin/python3.7 /Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/tmprosed3kj:
  Traceback (most recent call last):
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 47, in <module>
      from build import *
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/build.py", line 7, in <module>
      from pip._vendor import pytoml
  ModuleNotFoundError: No module named 'pip'
@dlamblin

This comment has been minimized.

Copy link

dlamblin commented Jan 23, 2019

Also the installation of the following also doesn't work with pip v 19.0 but would if using the --no-use-pep5517:
pendulum==1.5.0 (AttributeError: module 'enum' has no attribute 'IntFlag')
pendulum==1.5.1 (AttributeError: module 'enum' has no attribute 'IntFlag')
pendulum==2.0.0 (AttributeError: module 'enum' has no attribute 'IntFlag')
pendulum==2.0.1 (AttributeError: module 'enum' has no attribute 'IntFlag')
pendulum==2.0.2 (AttributeError: module 'enum' has no attribute 'IntFlag')

Whereas 2.0.3 and 2.0.4 install fine.

htgoebel added a commit to htgoebel/pyinstaller that referenced this issue Jan 23, 2019

Tests: CI: Temporary pin pip to < 19.0.
pip 19.0 fails to install PyInstaller, see pypa/pip#6163. Until this is
solve d (or another solution is provided), pin pip.
@TimoRoth

This comment has been minimized.

Copy link

TimoRoth commented Jan 23, 2019

cartopy(At least their latest release) also fails to install since 19.0, failing to import its versioneer.py that's next to setup.py

yan12125 added a commit to yan12125/buildbot that referenced this issue Jan 23, 2019

htgoebel added a commit to htgoebel/pyinstaller that referenced this issue Jan 23, 2019

Tests: CI: Temporary pin pip to < 19.0.
pip 19.0 fails to install PyInstaller, see pypa/pip#6163. Until this is
solve d (or another solution is provided), pin pip.

LefterisJP added a commit to LefterisJP/raiden that referenced this issue Jan 23, 2019

Don't install pyinstaller and s3cmd in jobs that don't need it
This will also probably circumvent the pip 19.0 pyinstaller
[bug](pypa/pip#6163) that hit us in all
Travis jobs. Example: https://travis-ci.org/raiden-network/raiden/jobs/483407811
@fchorney

This comment has been minimized.

Copy link

fchorney commented Jan 23, 2019

This is also an issue with some projects that I deal with. We use a pyproject.toml to define our python black parameters, and do a similar from project.version import __version__ in our setup.py.

At the very least I feel like being able to define no project isolation in the pyproject.toml would be sufficient. It seems unreasonable to me to make anybody wanting to install the project to use --no-buid-isolation or --no-use-pep517

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jan 23, 2019

The failure appears to be in get_requires_for_build_wheel, and the setuptools backend runs setup.py to do some sort of introspection to determine build requirements (the specific code is here). That code appears weird to me, and I don't understand why it's required. My initial instinct is that this is a bug in the setuptools backend that should be addressed by them.

PEP 517 does not state that frontends should run hooks in an environment that adds the build directory to sys.path, and there's a potential concern that if we did that, it could break isolation (if the build directory contained a copy of some required but not specified package, for instance). So my preference would be to not add the build directory to sys.path. But it may be expedient to do so if that offers a quick fix for this regression. I don't think projects should rely on this, though.

Summary:

  1. This should be reported to setuptools for review as a backend issue. I'd consider fixing it in the setuptools backend (possibly just by them adding the build directory to sys.path) as the ideal resolution.
  2. If setuptools doesn't do it, pip could add the build directory to sys.path, but I don't think that PEP 517 views that as the frontend's responsibility..
  3. Requiring the build directory to be visible to hooks on sys.path would require at least a PEP clarification.

I don't think this scenario was considered when PEP 517 was being developed. Maybe because it's setuptools-specific (or rather, specific to backends that run arbitrary Python code as part of the build).

@dstufft

This comment has been minimized.

Copy link
Member

dstufft commented Jan 23, 2019

I think it's fairly common for people to import something from the current directory into a setup.py, and just generally treat things as if setup.py is in $PWD.

I think it's reasonable to push this responsibility onto setuptools, since that's probably the only project that really needs it.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jan 23, 2019

Yep, thinking about this some more, I'm certain it's a setuptools backend responsibility. Pre-PEP 517, pip ran setup.py as a script, so standard Python rules put the script directory onto sys.path. Under PEP 517, invocation of setup.py is replaced with calls to the backend hooks, so those hooks need to preserve the semantics. Because setuptools runs setup.py in-process from the hooks, it needs to manage sys.path itself. Hopefully, it's not a big fix for them. @jeanlaroche (or someone else hitting this issue) could you raise an issue on the setuptools tracker, referring back to this thread?

@Overdrivr

This comment has been minimized.

Copy link

Overdrivr commented Feb 5, 2019

@altendky Sadly, using a predefined version of pip is not possible at the time for pipenv (and also for poetry I think) users. Both use latest versions. So I'm guessing many people are stuck with broken pipelines for now

@Overdrivr

This comment has been minimized.

Copy link

Overdrivr commented Feb 5, 2019

What's even more weird, it's not happening consistently. I've rerun an Appveyor job, the first one passed, the second one failed although they are strictly identical

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Feb 5, 2019

In case anyone's wondering about the timeline, I expect we'll be able to have a fix ready by the end of this week or early next week and make a subsequent bug-fix release of pip soon after that.

@pganssle

This comment has been minimized.

Copy link
Member

pganssle commented Feb 5, 2019

The new version of setuptools, version 40.8.0 is now available with the build_meta:__legacy__ backend.

@AlmogCohen

This comment has been minimized.

Copy link

AlmogCohen commented Feb 5, 2019

@pganssle

This comment has been minimized.

Copy link
Member

pganssle commented Feb 5, 2019

@AlmogCohen No, this is not something you should use directly, it is only for use by PEP 517 front-ends. The next step is for pip to start using build_meta:__legacy__ as its default backend. This is not actionable from an end-user's perspective.

mindlessroman added a commit to Microsoft/cadet-cli that referenced this issue Feb 5, 2019

Hotfix: Progressbar/Time Remaining More Accurate During Import (#11)
* Swaps in the progress bar update unit to the row and not the document
size. Also adds in more references to the delimiter and file endings
variables for easier future updating,

* Fixes a possible capitalization problem with a linux build.

* Adds the flag in `pip install` to not use PEP517 per a discussion on
pypa/pip#6163

* Removes the `--no-use-pep517` flag on the Mac build. Prematurely added.

msullivan added a commit to python/mypy that referenced this issue Feb 5, 2019

Delete pyproject.toml to work around pip bug
We run afoul of pypa/pip#6163, which
prevents directly pip installing mypy from a source directory with pip
19.0 (because our setup.py imports from mypy for version number
related reasons).

Once a bugfix for that is out we can probably restore it.

gvanrossum added a commit to python/mypy that referenced this issue Feb 5, 2019

Delete pyproject.toml to work around pip bug (#6342)
We run afoul of pypa/pip#6163, which
prevents directly pip installing mypy from a source directory with pip
19.0 (because our setup.py imports from mypy for version number
related reasons).

Once a bugfix for that is out we can probably restore it.

gvanrossum added a commit to gvanrossum/mypy that referenced this issue Feb 5, 2019

Delete pyproject.toml to work around pip bug (python#6342)
We run afoul of pypa/pip#6163, which
prevents directly pip installing mypy from a source directory with pip
19.0 (because our setup.py imports from mypy for version number
related reasons).

Once a bugfix for that is out we can probably restore it.

ncoghlan added a commit to ncoghlan/pip that referenced this issue Feb 6, 2019

Fix pypa#6163: Default to setuptools.build_meta:__legacy__
The main setuptools PEP 517 backend is intended for
explicit usage in `pyproject.toml`, when the project
authors can ensure that their `setup.py` runs without
that directory being implicitly on `sys.path`.

For implicit usage, setuptools now offers a separate
legacy backend that more closely mimics direct
execution of the `setup.py` script.

@pradyunsg pradyunsg closed this in 682cff7 Feb 6, 2019

pradyunsg added a commit that referenced this issue Feb 6, 2019

Merge pull request #6212 from ncoghlan/issue-6163-use-setuptools-buil…
…d-meta-legacy-backend

Fix #6163: Default to setuptools.build_meta:__legacy__
@Overdrivr

This comment has been minimized.

Copy link

Overdrivr commented Feb 7, 2019

Any ETA on the new release that will integrate the fix ?

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Feb 8, 2019

In a few hours. :)

See the pinned issue.

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Feb 9, 2019

pip 19.0.2 has been released with a fix for this.

@pradyunsg pradyunsg unpinned this issue Feb 11, 2019

bors bot added a commit to mozilla/normandy that referenced this issue Feb 11, 2019

Merge #1726 #1732
1726: Update python:3.7-slim Docker digest to 8a125f6 r=peterbe a=renovate[bot]

This PR contains the following updates:

| Package | Update | Change |
|---|---|---|
| python | digest | `3.7-slim` -> `8a125f6` |


1732: Scheduled weekly dependency update for week 06 r=peterbe a=pyup-bot






### Update [botocore](https://pypi.org/project/botocore) from **1.12.86** to **1.12.91**.


<details>
  <summary>Changelog</summary>
  
  
   ### 1.12.91
   ```
   =======

* api-change:``discovery``: Update discovery client to latest version
* api-change:``ecs``: Update ecs client to latest version
* api-change:``dlm``: Update dlm client to latest version
   ```
   
  
  
   ### 1.12.90
   ```
   =======

* api-change:``es``: Update es client to latest version
* api-change:``medialive``: Update medialive client to latest version
* api-change:``gamelift``: Update gamelift client to latest version
* api-change:``robomaker``: Update robomaker client to latest version
   ```
   
  
  
   ### 1.12.89
   ```
   =======

* api-change:``ec2``: Update ec2 client to latest version
* api-change:``fsx``: Update fsx client to latest version
   ```
   
  
  
   ### 1.12.88
   ```
   =======

* api-change:``shield``: Update shield client to latest version
* api-change:``servicecatalog``: Update servicecatalog client to latest version
* api-change:``ec2``: Update ec2 client to latest version
   ```
   
  
  
   ### 1.12.87
   ```
   =======

* api-change:``ecs``: Update ecs client to latest version
* api-change:``application-autoscaling``: Update application-autoscaling client to latest version
* api-change:``workspaces``: Update workspaces client to latest version
* api-change:``codecommit``: Update codecommit client to latest version
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/botocore
  - Changelog: https://pyup.io/changelogs/botocore/
  - Repo: https://github.com/boto/botocore
</details>





### Update [python-dateutil](https://pypi.org/project/python-dateutil) from **2.7.5** to **2.8.0**.


<details>
  <summary>Changelog</summary>
  
  
   ### 2.8.0
   ```
   ==========================

Data updates
------------

- Updated tzdata version to to 2018i.


Features
--------

- Added support for ``EXDATE`` parameters when parsing ``rrule`` strings.
  Reported by mlorant (gh issue 410), fixed by nicoe (gh pr 859).
- Added support for sub-minute time zone offsets in Python 3.6+.
  Fixed by cssherry (gh issue 582, pr 763)
- Switched the ``tzoffset``, ``tzstr`` and ``gettz`` caches over to using weak
  references, so that the cache expires when no other references to the
  original ``tzinfo`` objects exist. This cache-expiry behavior is not
  guaranteed in the public interface and may change in the future. To improve
  performance in the case where transient references to the same time zones
  are repeatedly created but no strong reference is continuously held, a
  smaller &quot;strong value&quot; cache was also added. Weak value cache implemented by
  cs-cordero (gh pr 672, 801), strong cache added by
  Gökçen Nurlu (gh issue 691, gh pr 761)


Bugfixes
--------

- Added time zone inference when initializing an ``rrule`` with a specified
  ``UNTIL`` but without an explicitly specified ``DTSTART``; the time zone
  of the generated ``DTSTART`` will now be taken from the ``UNTIL`` rule.
  Reported by href (gh issue 652). Fixed by absreim (gh pr 693).
- Fixed an issue where ``parser.parse`` would raise ``Decimal``-specific errors
  instead of a standard ``ValueError`` if certain malformed values were parsed
  (e.g. ``NaN`` or infinite values). Reported and fixed by
  amureki (gh issue 662, gh pr 679).
- Fixed issue in ``parser`` where a ``tzinfos`` call explicitly returning
  ``None`` would throw a ``ValueError``.
  Fixed by parsethis (gh issue 661, gh pr 681)
- Fixed incorrect parsing of certain dates earlier than 100 AD when repesented
  in the form &quot;%B.%Y.%d&quot;, e.g. &quot;December.0031.30&quot;. (gh issue 687, pr 700)
- Add support for ISO 8601 times with comma as the decimal separator in the
  ``dateutil.parser.isoparse`` function. (gh pr 721)
- Changed handling of ``T24:00`` to be compliant with the standard. ``T24:00``
  now represents midnight on the *following* day.
  Fixed by cheukting (gh issue 658, gh pr 751)
- Fixed an issue where ``isoparser.parse_isotime`` was unable to handle the
  ``24:00`` variant representation of midnight. (gh pr 773)
- Added support for more than 6 fractional digits in `isoparse`.
  Reported and fixed by jayschwa (gh issue 786, gh pr 787).
- Added &#39;z&#39; (lower case Z) as valid UTC time zone in isoparser.
  Reported by cjgibson (gh issue 820). Fixed by Cheukting (gh pr 822)
- Fixed a bug with base offset changes during DST in ``tzfile``, and refactored
  the way base offset changes are detected. Originally reported on
  StackOverflow by MartinThoma. (gh issue 812, gh pr 810)
- Fixed error condition in ``tz.gettz`` when a non-ASCII timezone is passed on
  Windows in Python 2.7. (gh issue 802, pr 861)
- Improved performance and inspection properties of ``tzname`` methods.
  (gh pr 811)
- Removed unnecessary binary_type compatibility shims.
  Added by jdufresne (gh pr 817)
- Changed ``python setup.py test`` to print an error to ``stderr`` and exit
  with 1 instead of 0. Reported and fixed by hroncok (gh pr 814)
- Added a ``pyproject.toml`` file with build requirements and an explicitly
  specified build backend. (gh issue 736, gh prs 746, 863)


Documentation changes
---------------------

- Added documentation for the ``rrule.rrulestr`` function.
  Fixed by prdickson (gh issue 623, gh pr 762)
- Added documentation for ``dateutil.tz.gettz``.
  Fixed by weatherpattern (gh issue 647, gh pr 704)
- Add documentation for the ``dateutil.tz.win`` module and mocked out certain
  Windows-specific modules so that autodoc can still be run on non-Windows
  systems. (gh issue 442, pr 715)
- Added changelog to documentation. (gh issue 692, gh pr 707)
- Changed order of keywords in the ``rrule`` docstring.
  Reported and fixed by rmahajan14 (gh issue 686, gh pr 695).
- Improved documentation on the use of ``until`` and ``count`` parameters in
  ``rrule``. Fixed by lucaferocino (gh pr 755).
- Added an example of how to use a custom ``parserinfo`` subclass to parse
  non-standard datetime formats in the examples documentation for ``parser``.
  Added by prdickson (gh 753)
- Added doctest examples to ``tzfile`` documentation.
  Patch by weatherpattern (gh pr 671)
- Updated the documentation for ``relativedelta``&#39;s ``weekday`` arguments.
  Fixed by kvn219 huangy22 and ElliotJH (gh pr 673)
- Improved explanation of the order that ``relativedelta`` components are
  applied in. Fixed by kvn219 huangy22 and ElliotJH (gh pr 673)
- Expanded the description and examples in the ``relativedelta`` class.
  Contributed by andrewcbennett (gh pr 759)
- Improved the contributing documentation to clarify where to put new changelog
  files. Contributed by andrewcbennett (gh pr 757)
- Fixed a broken doctest in the ``relativedelta`` module.
  Fixed by nherriot (gh pr 758).
- Changed the default theme to ``sphinx_rtd_theme``, and changed the sphinx
  configuration accordingly. (gh pr 707)
- Reorganized ``dateutil.tz`` documentation and fixed issue with the
  ``dateutil.tz`` docstring. (gh pr 714)
- Cleaned up malformed RST in the ``tz`` documentation.
  (gh issue 702, gh pr 706)
- Corrected link syntax and updated URL to https for ISO year week number
  notation in ``relativedelta`` examples. (gh issue 670, pr 711)


Misc
----

- GH 674, GH 688, GH 699, GH 720, GH 723, GH 726, GH 727, GH 740,
  GH 750, GH 760, GH 767, GH 772, GH 773, GH 780, GH 784, GH 785,
  GH 791, GH 799, GH 813, GH 836, GH 839, GH 857
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/python-dateutil
  - Changelog: https://pyup.io/changelogs/python-dateutil/
  - Docs: https://dateutil.readthedocs.io
</details>





### Update [s3transfer](https://pypi.org/project/s3transfer) from **0.1.13** to **0.2.0**.


<details>
  <summary>Changelog</summary>
  
  
   ### 0.2.0
   ```
   =====

* feature:``ProcessPoolDownloader``: Add ``ProcessPoolDownloader`` class to speed up download throughput by using processes instead of threads.
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/s3transfer
  - Changelog: https://pyup.io/changelogs/s3transfer/
  - Repo: https://github.com/boto/s3transfer
</details>





### Update [setuptools](https://pypi.org/project/setuptools) from **40.7.3** to **40.8.0**.


<details>
  <summary>Changelog</summary>
  
  
   ### 40.8.0
   ```
   -------

* 1652: Added the ``build_meta:__legacy__`` backend, a &quot;compatibility mode&quot; PEP 517 backend that can be used as the default when ``build-backend`` is left unspecified in ``pyproject.toml``.
* 1635: Resource paths are passed to ``pkg_resources.resource_string`` and similar no longer accept paths that traverse parents, that begin with a leading ``/``. Violations of this expectation raise DeprecationWarnings and will become errors. Additionally, any paths that are absolute on Windows are strictly disallowed and will raise ValueErrors.
* 1536: ``setuptools`` will now automatically include licenses if ``setup.cfg`` contains a ``license_file`` attribute, unless this file is manually excluded inside ``MANIFEST.in``.
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/setuptools
  - Changelog: https://pyup.io/changelogs/setuptools/
  - Repo: https://github.com/pypa/setuptools
</details>





### Update [boto3](https://pypi.org/project/boto3) from **1.9.86** to **1.9.91**.


<details>
  <summary>Changelog</summary>
  
  
   ### 1.9.91
   ```
   ======

* api-change:``discovery``: [``botocore``] Update discovery client to latest version
* api-change:``ecs``: [``botocore``] Update ecs client to latest version
* api-change:``dlm``: [``botocore``] Update dlm client to latest version
   ```
   
  
  
   ### 1.9.90
   ```
   ======

* api-change:``es``: [``botocore``] Update es client to latest version
* api-change:``medialive``: [``botocore``] Update medialive client to latest version
* api-change:``gamelift``: [``botocore``] Update gamelift client to latest version
* api-change:``robomaker``: [``botocore``] Update robomaker client to latest version
   ```
   
  
  
   ### 1.9.89
   ```
   ======

* api-change:``ec2``: [``botocore``] Update ec2 client to latest version
* api-change:``fsx``: [``botocore``] Update fsx client to latest version
   ```
   
  
  
   ### 1.9.88
   ```
   ======

* api-change:``shield``: [``botocore``] Update shield client to latest version
* api-change:``servicecatalog``: [``botocore``] Update servicecatalog client to latest version
* api-change:``ec2``: [``botocore``] Update ec2 client to latest version
   ```
   
  
  
   ### 1.9.87
   ```
   ======

* api-change:``ecs``: [``botocore``] Update ecs client to latest version
* api-change:``application-autoscaling``: [``botocore``] Update application-autoscaling client to latest version
* api-change:``workspaces``: [``botocore``] Update workspaces client to latest version
* api-change:``codecommit``: [``botocore``] Update codecommit client to latest version
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/boto3
  - Changelog: https://pyup.io/changelogs/boto3/
  - Repo: https://github.com/boto/boto3
</details>





### Update [Django](https://pypi.org/project/Django) from **2.0.10** to **2.0.12**.


<details>
  <summary>Changelog</summary>
  
  
   ### 2.0.12
   ```
   ===========================

*February 11, 2019*

Django 2.0.12 fixes a packaging error in 2.0.11.

Bugfixes
========

* Corrected packaging error from 2.0.11 (🎫`30175`).


===========================
   ```
   
  
  
   ### 2.0.11
   ```
   ===========================

*February 11, 2019*

Django 2.0.11 fixes a security issue in 2.0.10.

CVE-2019-6975: Memory exhaustion in ``django.utils.numberformat.format()``
--------------------------------------------------------------------------

If ``django.utils.numberformat.format()`` -- used by ``contrib.admin`` as well
as the the ``floatformat``, ``filesizeformat``, and ``intcomma`` templates
filters -- received a ``Decimal`` with a large number of digits or a large
exponent, it could lead to significant memory usage due to a call to
``&#39;{:f}&#39;.format()``.

To avoid this, decimals with more than 200 digits are now formatted using
scientific notation.


===========================
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/django
  - Changelog: https://pyup.io/changelogs/django/
  - Homepage: https://www.djangoproject.com/
</details>





### Update [pytest-testrail](https://pypi.org/project/pytest-testrail) from **2.3.2** to **2.3.3**.


<details>
  <summary>Changelog</summary>
  
  
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/pytest-testrail
  - Changelog: https://pyup.io/changelogs/pytest-testrail/
  - Repo: http://github.com/allankp/pytest-testrail/
</details>





### Update [pip](https://pypi.org/project/pip) from **19.0.1** to **19.0.2**.


<details>
  <summary>Changelog</summary>
  
  
   ### 19.0.2
   ```
   ===================

Bug Fixes
---------

- Fix a crash where PEP 517-based builds using ``--no-cache-dir`` would fail in
  some circumstances with an ``AssertionError`` due to not finalizing a build
  directory internally. (`6197 &lt;https://github.com/pypa/pip/issues/6197&gt;`_)
- Provide a better error message if attempting an editable install of a
  directory with a ``pyproject.toml`` but no ``setup.py``. (`6170 &lt;https://github.com/pypa/pip/issues/6170&gt;`_)
- The implicit default backend used for projects that provide a ``pyproject.toml``
  file without explicitly specifying ``build-backend`` now behaves more like direct
  execution of ``setup.py``, and hence should restore compatibility with projects
  that were unable to be installed with ``pip`` 19.0. This raised the minimum
  required version of ``setuptools`` for such builds to 40.8.0. (`6163 &lt;https://github.com/pypa/pip/issues/6163&gt;`_)
- Allow ``RECORD`` lines with more than three elements, and display a warning. (`6165 &lt;https://github.com/pypa/pip/issues/6165&gt;`_)
- ``AdjacentTempDirectory`` fails on unwritable directory instead of locking up the uninstall command. (`6169 &lt;https://github.com/pypa/pip/issues/6169&gt;`_)
- Make failed uninstalls roll back more reliably and better at avoiding naming conflicts. (`6194 &lt;https://github.com/pypa/pip/issues/6194&gt;`_)
- Ensure the correct wheel file is copied when building PEP 517 distribution is built. (`6196 &lt;https://github.com/pypa/pip/issues/6196&gt;`_)
- The Python 2 end of life warning now only shows on CPython, which is the
  implementation that has announced end of life plans. (`6207 &lt;https://github.com/pypa/pip/issues/6207&gt;`_)

Improved Documentation
----------------------

- Re-write README and documentation index (`5815 &lt;https://github.com/pypa/pip/issues/5815&gt;`_)
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/pip
  - Changelog: https://pyup.io/changelogs/pip/
  - Homepage: https://pip.pypa.io/
</details>







Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: pyup-bot <github-bot@pyup.io>

apraovjr pushed a commit to cse-airflow/incubator-airflow that referenced this issue Feb 14, 2019

[AIRFLOW-XXX] Pin version of Pip in tests to work around pypa/pip#6163 (
apache#4576)

There is a bug or a new feature that causes a number of our dependencies
to fail to install.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment