Pipenv fails to honor version constraints

Issue description
Pipenv installs urllib3 at version 1.25.3 when there are constraints that require <1.25.
Expected result
Pipenv honors all version constraints or fails to install the packages with an error message.
Actual result
Installing docker-compose as a dev-package and elasticsearch as a package results in installing urllib3 version 1.25.3 which violates the constraint placed by docker-compose (via requests).
pipenv graph
docker-compose==1.24.1
  - cached-property [required: >=1.2.0,<2, installed: 1.5.1]
  - docker [required: >=3.7.0,<4.0, installed: 3.7.3]
    - docker-pycreds [required: >=0.4.0, installed: 0.4.0]
      - six [required: >=1.4.0, installed: 1.12.0]
    - requests [required: >=2.14.2,!=2.18.0, installed: 2.20.1]
      - certifi [required: >=2017.4.17, installed: 2019.6.16]
      - chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
      - idna [required: >=2.5,<2.8, installed: 2.7]
      - urllib3 [required: >=1.21.1,<1.25, installed: 1.25.3]
    - six [required: >=1.4.0, installed: 1.12.0]
    - websocket-client [required: >=0.32.0, installed: 0.56.0]
      - six [required: Any, installed: 1.12.0]
  - dockerpty [required: >=0.4.1,<0.5, installed: 0.4.1]
    - six [required: >=1.3.0, installed: 1.12.0]
  - docopt [required: >=0.6.1,<0.7, installed: 0.6.2]
  - jsonschema [required: >=2.5.1,<3, installed: 2.6.0]
  - PyYAML [required: >=3.10,<4.3, installed: 3.13]
  - requests [required: >=2.6.1,<2.21,!=2.18.0,!=2.12.2,!=2.11.0, installed: 2.20.1]
    - certifi [required: >=2017.4.17, installed: 2019.6.16]
    - chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
    - idna [required: >=2.5,<2.8, installed: 2.7]
    - urllib3 [required: >=1.21.1,<1.25, installed: 1.25.3]
  - six [required: >=1.3.0,<2, installed: 1.12.0]
  - texttable [required: >=0.9.0,<0.10, installed: 0.9.1]
  - websocket-client [required: >=0.32.0,<1.0, installed: 0.56.0]
    - six [required: Any, installed: 1.12.0]
elasticsearch==7.0.4
  - urllib3 [required: >=1.21.1, installed: 1.25.3]
paramiko==2.6.0
  - bcrypt [required: >=3.1.3, installed: 3.1.7]
    - cffi [required: >=1.1, installed: 1.12.3]
      - pycparser [required: Any, installed: 2.19]
    - six [required: >=1.4.1, installed: 1.12.0]
  - cryptography [required: >=2.5, installed: 2.7]
    - asn1crypto [required: >=0.21.0, installed: 0.24.0]
    - cffi [required: >=1.8,!=1.11.3, installed: 1.12.3]
      - pycparser [required: Any, installed: 2.19]
    - six [required: >=1.4.1, installed: 1.12.0]
  - pynacl [required: >=1.0.1, installed: 1.3.0]
    - cffi [required: >=1.4.1, installed: 1.12.3]
      - pycparser [required: Any, installed: 2.19]
    - six [required: Any, installed: 1.12.0]

pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple
Using pip: -i https://pypi.org/simple
Using pip: -i https://pypi.org/simple

                          ROUND 1
Current constraints:
  docker-compose

Finding the best candidates:
  found candidate docker-compose==1.24.1 (constraint was <any>)

Finding secondary dependencies:
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0

New dependencies found in this round:
  adding ['cached-property', '<2,>=1.2.0', '[]']
  adding ['docker', '<4.0,>=3.7.0', "['ssh']"]
  adding ['dockerpty', '<0.5,>=0.4.1', '[]']
  adding ['docopt', '<0.7,>=0.6.1', '[]']
  adding ['jsonschema', '<3,>=2.5.1', '[]']
  adding ['pyyaml', '<4.3,>=3.10', '[]']
  adding ['requests', '!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1', '[]']
  adding ['six', '<2,>=1.3.0', '[]']
  adding ['texttable', '<0.10,>=0.9.0', '[]']
  adding ['websocket-client', '<1.0,>=0.32.0', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  cached-property<2,>=1.2.0
  docker[ssh]<4.0,>=3.7.0
  docker-compose
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  jsonschema<3,>=2.5.1
  pyyaml<4.3,>=3.10
  requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1
  six<2,>=1.3.0
  texttable<0.10,>=0.9.0
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate cached-property==1.5.1 (constraint was >=1.2.0,<2)
  found candidate docker[ssh]==3.7.3 (constraint was >=3.7.0,<4.0)
  found candidate docker-compose==1.24.1 (constraint was <any>)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate pyyaml==3.13 (constraint was >=3.10,<4.3)
  found candidate requests==2.20.1 (constraint was !=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1)
  found candidate six==1.12.0 (constraint was >=1.3.0,<2)
  found candidate texttable==0.9.1 (constraint was <0.10,>=0.9.0)
  found candidate websocket-client==0.56.0 (constraint was >=0.32.0,<1.0)

Finding secondary dependencies:
  pyyaml==3.13              requires -
  jsonschema==2.6.0         requires -
  websocket-client==0.56.0  requires six
  docker[ssh]==3.7.3        requires docker-pycreds>=0.4.0, paramiko>=2.4.2; extra == "ssh", requests!=2.18.0,>=2.14.2, six>=1.4.0, websocket-client>=0.32.0
  requests==2.20.1          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.8,>=2.5, urllib3<1.25,>=1.21.1
  docopt==0.6.2             requires -
  cached-property==1.5.1    requires -
  six==1.12.0               requires -
  texttable==0.9.1          requires -
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  dockerpty==0.4.1          requires six>=1.3.0

New dependencies found in this round:
  adding ['certifi', '>=2017.4.17', '[]']
  adding ['chardet', '<3.1.0,>=3.0.2', '[]']
  adding ['docker-pycreds', '>=0.4.0', '[]']
  adding ['idna', '<2.8,>=2.5', '[]']
  adding ['paramiko', '>=2.4.2', '[]']
  adding ['requests', '!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.14.2,>=2.6.1', '[]']
  adding ['six', '<2,>=1.3.0,>=1.4.0', '[]']
  adding ['urllib3', '<1.25,>=1.21.1', '[]']
Removed dependencies in this round:
  removing ['requests', '!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1', '[]']
  removing ['six', '<2,>=1.3.0', '[]']
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3
Current constraints:
  cached-property<2,>=1.2.0
  certifi>=2017.4.17
  chardet<3.1.0,>=3.0.2
  docker[ssh]<4.0,>=3.7.0
  docker-compose
  docker-pycreds>=0.4.0
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  idna<2.8,>=2.5
  jsonschema<3,>=2.5.1
  paramiko>=2.4.2
  pyyaml<4.3,>=3.10
  requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.14.2,>=2.6.1
  six<2,>=1.3.0,>=1.4.0
  texttable<0.10,>=0.9.0
  urllib3<1.25,>=1.21.1
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate cached-property==1.5.1 (constraint was >=1.2.0,<2)
  found candidate certifi==2019.6.16 (constraint was >=2017.4.17)
  found candidate chardet==3.0.4 (constraint was >=3.0.2,<3.1.0)
  found candidate docker[ssh]==3.7.3 (constraint was >=3.7.0,<4.0)
  found candidate docker-compose==1.24.1 (constraint was <any>)
  found candidate docker-pycreds==0.4.0 (constraint was >=0.4.0)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate idna==2.7 (constraint was >=2.5,<2.8)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate paramiko==2.6.0 (constraint was >=2.4.2)
  found candidate pyyaml==3.13 (constraint was >=3.10,<4.3)
  found candidate requests==2.20.1 (constraint was !=2.11.0,!=2.12.2,>=2.14.2,!=2.18.0,<2.21,>=2.6.1)
  found candidate six==1.12.0 (constraint was >=1.3.0,>=1.4.0,<2)
  found candidate texttable==0.9.1 (constraint was <0.10,>=0.9.0)
  found candidate urllib3==1.24.3 (constraint was >=1.21.1,<1.25)
  found candidate websocket-client==0.56.0 (constraint was >=0.32.0,<1.0)

Finding secondary dependencies:
  dockerpty==0.4.1          requires six>=1.3.0
  idna==2.7                 requires -
  requests==2.20.1          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.8,>=2.5, urllib3<1.25,>=1.21.1
  cached-property==1.5.1    requires -
  docopt==0.6.2             requires -
  six==1.12.0               requires -
  pyyaml==3.13              requires -
  docker[ssh]==3.7.3        requires docker-pycreds>=0.4.0, paramiko>=2.4.2; extra == "ssh", requests!=2.18.0,>=2.14.2, six>=1.4.0, websocket-client>=0.32.0
  certifi==2019.6.16        requires -
  websocket-client==0.56.0  requires six
  docker-pycreds==0.4.0     requires six>=1.4.0
  jsonschema==2.6.0         requires -
  texttable==0.9.1          requires -
  chardet==3.0.4            requires -
  urllib3==1.24.3           requires -
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  paramiko==2.6.0           requires bcrypt>=3.1.3, cryptography>=2.5, pynacl>=1.0.1

New dependencies found in this round:
  adding ['bcrypt', '>=3.1.3', '[]']
  adding ['cryptography', '>=2.5', '[]']
  adding ['pynacl', '>=1.0.1', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 3: not stable

                          ROUND 4
Current constraints:
  bcrypt>=3.1.3
  cached-property<2,>=1.2.0
  certifi>=2017.4.17
  chardet<3.1.0,>=3.0.2
  cryptography>=2.5
  docker[ssh]<4.0,>=3.7.0
  docker-compose
  docker-pycreds>=0.4.0
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  idna<2.8,>=2.5
  jsonschema<3,>=2.5.1
  paramiko>=2.4.2
  pynacl>=1.0.1
  pyyaml<4.3,>=3.10
  requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.14.2,>=2.6.1
  six<2,>=1.3.0,>=1.4.0
  texttable<0.10,>=0.9.0
  urllib3<1.25,>=1.21.1
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate bcrypt==3.1.7 (constraint was >=3.1.3)
  found candidate cached-property==1.5.1 (constraint was >=1.2.0,<2)
  found candidate certifi==2019.6.16 (constraint was >=2017.4.17)
  found candidate chardet==3.0.4 (constraint was >=3.0.2,<3.1.0)
  found candidate cryptography==2.7 (constraint was >=2.5)
  found candidate docker[ssh]==3.7.3 (constraint was >=3.7.0,<4.0)
  found candidate docker-compose==1.24.1 (constraint was <any>)
  found candidate docker-pycreds==0.4.0 (constraint was >=0.4.0)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate idna==2.7 (constraint was >=2.5,<2.8)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate paramiko==2.6.0 (constraint was >=2.4.2)
  found candidate pynacl==1.3.0 (constraint was >=1.0.1)
  found candidate pyyaml==3.13 (constraint was >=3.10,<4.3)
  found candidate requests==2.20.1 (constraint was !=2.11.0,!=2.12.2,>=2.14.2,!=2.18.0,<2.21,>=2.6.1)
  found candidate six==1.12.0 (constraint was >=1.3.0,>=1.4.0,<2)
  found candidate texttable==0.9.1 (constraint was <0.10,>=0.9.0)
  found candidate urllib3==1.24.3 (constraint was >=1.21.1,<1.25)
  found candidate websocket-client==0.56.0 (constraint was >=0.32.0,<1.0)

Finding secondary dependencies:
  urllib3==1.24.3           requires -
  six==1.12.0               requires -
  pynacl==1.3.0             requires cffi>=1.4.1, six
  pyyaml==3.13              requires -
  chardet==3.0.4            requires -
  requests==2.20.1          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.8,>=2.5, urllib3<1.25,>=1.21.1
  websocket-client==0.56.0  requires six
  docker[ssh]==3.7.3        requires docker-pycreds>=0.4.0, paramiko>=2.4.2; extra == "ssh", requests!=2.18.0,>=2.14.2, six>=1.4.0, websocket-client>=0.32.0
  docopt==0.6.2             requires -
  idna==2.7                 requires -
  cached-property==1.5.1    requires -
  bcrypt==3.1.7             requires cffi>=1.1, six>=1.4.1
  docker-pycreds==0.4.0     requires six>=1.4.0
  texttable==0.9.1          requires -
  paramiko==2.6.0           requires bcrypt>=3.1.3, cryptography>=2.5, pynacl>=1.0.1
  certifi==2019.6.16        requires -
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  jsonschema==2.6.0         requires -
  cryptography==2.7         requires asn1crypto>=0.21.0, cffi!=1.11.3,>=1.8, six>=1.4.1
  dockerpty==0.4.1          requires six>=1.3.0

New dependencies found in this round:
  adding ['asn1crypto', '>=0.21.0', '[]']
  adding ['cffi', '!=1.11.3,>=1.1,>=1.4.1,>=1.8', '[]']
  adding ['six', '<2,>=1.3.0,>=1.4.0,>=1.4.1', '[]']
Removed dependencies in this round:
  removing ['six', '<2,>=1.3.0,>=1.4.0', '[]']
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 4: not stable

                          ROUND 5
Current constraints:
  asn1crypto>=0.21.0
  bcrypt>=3.1.3
  cached-property<2,>=1.2.0
  certifi>=2017.4.17
  cffi!=1.11.3,>=1.1,>=1.4.1,>=1.8
  chardet<3.1.0,>=3.0.2
  cryptography>=2.5
  docker[ssh]<4.0,>=3.7.0
  docker-compose
  docker-pycreds>=0.4.0
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  idna<2.8,>=2.5
  jsonschema<3,>=2.5.1
  paramiko>=2.4.2
  pynacl>=1.0.1
  pyyaml<4.3,>=3.10
  requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.14.2,>=2.6.1
  six<2,>=1.3.0,>=1.4.0,>=1.4.1
  texttable<0.10,>=0.9.0
  urllib3<1.25,>=1.21.1
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate asn1crypto==0.24.0 (constraint was >=0.21.0)
  found candidate bcrypt==3.1.7 (constraint was >=3.1.3)
  found candidate cached-property==1.5.1 (constraint was >=1.2.0,<2)
  found candidate certifi==2019.6.16 (constraint was >=2017.4.17)
  found candidate cffi==1.12.3 (constraint was >=1.1,!=1.11.3,>=1.4.1,>=1.8)
  found candidate chardet==3.0.4 (constraint was >=3.0.2,<3.1.0)
  found candidate cryptography==2.7 (constraint was >=2.5)
  found candidate docker[ssh]==3.7.3 (constraint was >=3.7.0,<4.0)
  found candidate docker-compose==1.24.1 (constraint was <any>)
  found candidate docker-pycreds==0.4.0 (constraint was >=0.4.0)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate idna==2.7 (constraint was >=2.5,<2.8)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate paramiko==2.6.0 (constraint was >=2.4.2)
  found candidate pynacl==1.3.0 (constraint was >=1.0.1)
  found candidate pyyaml==3.13 (constraint was >=3.10,<4.3)
  found candidate requests==2.20.1 (constraint was !=2.11.0,!=2.12.2,>=2.14.2,!=2.18.0,<2.21,>=2.6.1)
  found candidate six==1.12.0 (constraint was >=1.3.0,>=1.4.0,>=1.4.1,<2)
  found candidate texttable==0.9.1 (constraint was <0.10,>=0.9.0)
  found candidate urllib3==1.24.3 (constraint was >=1.21.1,<1.25)
  found candidate websocket-client==0.56.0 (constraint was >=0.32.0,<1.0)

Finding secondary dependencies:
  dockerpty==0.4.1          requires six>=1.3.0
  certifi==2019.6.16        requires -
  idna==2.7                 requires -
  texttable==0.9.1          requires -
  bcrypt==3.1.7             requires cffi>=1.1, six>=1.4.1
  urllib3==1.24.3           requires -
  paramiko==2.6.0           requires bcrypt>=3.1.3, cryptography>=2.5, pynacl>=1.0.1
  docker[ssh]==3.7.3        requires docker-pycreds>=0.4.0, paramiko>=2.4.2; extra == "ssh", requests!=2.18.0,>=2.14.2, six>=1.4.0, websocket-client>=0.32.0
  pyyaml==3.13              requires -
  requests==2.20.1          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.8,>=2.5, urllib3<1.25,>=1.21.1
  websocket-client==0.56.0  requires six
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  pynacl==1.3.0             requires cffi>=1.4.1, six
  cffi==1.12.3              requires pycparser
  docopt==0.6.2             requires -
  asn1crypto==0.24.0        requires -
  chardet==3.0.4            requires -
  jsonschema==2.6.0         requires -
  cryptography==2.7         requires asn1crypto>=0.21.0, cffi!=1.11.3,>=1.8, six>=1.4.1
  docker-pycreds==0.4.0     requires six>=1.4.0
  cached-property==1.5.1    requires -
  six==1.12.0               requires -

New dependencies found in this round:
  adding ['pycparser', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 5: not stable

                          ROUND 6
Current constraints:
  asn1crypto>=0.21.0
  bcrypt>=3.1.3
  cached-property<2,>=1.2.0
  certifi>=2017.4.17
  cffi!=1.11.3,>=1.1,>=1.4.1,>=1.8
  chardet<3.1.0,>=3.0.2
  cryptography>=2.5
  docker[ssh]<4.0,>=3.7.0
  docker-compose
  docker-pycreds>=0.4.0
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  idna<2.8,>=2.5
  jsonschema<3,>=2.5.1
  paramiko>=2.4.2
  pycparser
  pynacl>=1.0.1
  pyyaml<4.3,>=3.10
  requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.14.2,>=2.6.1
  six<2,>=1.3.0,>=1.4.0,>=1.4.1
  texttable<0.10,>=0.9.0
  urllib3<1.25,>=1.21.1
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate asn1crypto==0.24.0 (constraint was >=0.21.0)
  found candidate bcrypt==3.1.7 (constraint was >=3.1.3)
  found candidate cached-property==1.5.1 (constraint was >=1.2.0,<2)
  found candidate certifi==2019.6.16 (constraint was >=2017.4.17)
  found candidate cffi==1.12.3 (constraint was >=1.1,!=1.11.3,>=1.4.1,>=1.8)
  found candidate chardet==3.0.4 (constraint was >=3.0.2,<3.1.0)
  found candidate cryptography==2.7 (constraint was >=2.5)
  found candidate docker[ssh]==3.7.3 (constraint was >=3.7.0,<4.0)
  found candidate docker-compose==1.24.1 (constraint was <any>)
  found candidate docker-pycreds==0.4.0 (constraint was >=0.4.0)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate idna==2.7 (constraint was >=2.5,<2.8)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate paramiko==2.6.0 (constraint was >=2.4.2)
  found candidate pycparser==2.19 (constraint was <any>)
  found candidate pynacl==1.3.0 (constraint was >=1.0.1)
  found candidate pyyaml==3.13 (constraint was >=3.10,<4.3)
  found candidate requests==2.20.1 (constraint was !=2.11.0,!=2.12.2,>=2.14.2,!=2.18.0,<2.21,>=2.6.1)
  found candidate six==1.12.0 (constraint was >=1.3.0,>=1.4.0,>=1.4.1,<2)
  found candidate texttable==0.9.1 (constraint was <0.10,>=0.9.0)
  found candidate urllib3==1.24.3 (constraint was >=1.21.1,<1.25)
  found candidate websocket-client==0.56.0 (constraint was >=0.32.0,<1.0)

Finding secondary dependencies:
  asn1crypto==0.24.0        requires -
  cryptography==2.7         requires asn1crypto>=0.21.0, cffi!=1.11.3,>=1.8, six>=1.4.1
  certifi==2019.6.16        requires -
  docker[ssh]==3.7.3        requires docker-pycreds>=0.4.0, paramiko>=2.4.2; extra == "ssh", requests!=2.18.0,>=2.14.2, six>=1.4.0, websocket-client>=0.32.0
  docker-compose==1.24.1    requires cached-property<2,>=1.2.0, docker[ssh]<4.0,>=3.7.0, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, pyyaml<4.3,>=3.10, requests!=2.11.0,!=2.12.2,!=2.18.0,<2.21,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  idna==2.7                 requires -
  pyyaml==3.13              requires -
  cached-property==1.5.1    requires -
  six==1.12.0               requires -
  pynacl==1.3.0             requires cffi>=1.4.1, six
  bcrypt==3.1.7             requires cffi>=1.1, six>=1.4.1
  paramiko==2.6.0           requires bcrypt>=3.1.3, cryptography>=2.5, pynacl>=1.0.1
  websocket-client==0.56.0  requires six
  cffi==1.12.3              requires pycparser
  dockerpty==0.4.1          requires six>=1.3.0
  jsonschema==2.6.0         requires -
  chardet==3.0.4            requires -
  docopt==0.6.2             requires -
  pycparser==2.19           requires -
  urllib3==1.24.3           requires -
  docker-pycreds==0.4.0     requires six>=1.4.0
  requests==2.20.1          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.8,>=2.5, urllib3<1.25,>=1.21.1
  texttable==0.9.1          requires -
------------------------------------------------------------
Result of round 6: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple
Using pip: -i https://pypi.org/simple
Using pip: -i https://pypi.org/simple

                          ROUND 1
Current constraints:
  elasticsearch

Finding the best candidates:
  found candidate elasticsearch==7.0.4 (constraint was <any>)

Finding secondary dependencies:
  elasticsearch==7.0.4      requires urllib3>=1.21.1

New dependencies found in this round:
  adding ['urllib3', '>=1.21.1', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  elasticsearch
  urllib3>=1.21.1

Finding the best candidates:
  found candidate elasticsearch==7.0.4 (constraint was <any>)
  found candidate urllib3==1.25.3 (constraint was >=1.21.1)

Finding secondary dependencies:
  urllib3==1.25.3           requires -
  elasticsearch==7.0.4      requires urllib3>=1.21.1
------------------------------------------------------------
Result of round 2: stable, done

Updated Pipfile.lock (16be6f)!

Steps to replicate
$ pipenv --support
Pipenv version: '2018.11.26'
Pipenv location: '/home/matthew/.local/lib/python3.6/site-packages/pipenv'
Python location: '/usr/bin/python3'
Python installations found:

3.7.4: /home/matthew/.pyenv/versions/3.7.4/bin/python3.7m
3.7.4: /home/matthew/.pyenv/versions/3.7.4/bin/python3
3.7.3: /home/matthew/.pyenv/versions/3.7.3/bin/python3.7m
3.7.3: /home/matthew/.pyenv/versions/3.7.3/bin/python3
3.7.2: /home/matthew/.pyenv/versions/3.7.2/bin/python3.7m
3.7.2: /home/matthew/.pyenv/versions/3.7.2/bin/python3
3.7.1: /home/matthew/.pyenv/versions/3.7.1/bin/python3.7m
3.7.1: /home/matthew/.pyenv/versions/3.7.1/bin/python3
3.7.0: /home/matthew/.pyenv/versions/3.7.0/bin/python3.7m
3.7.0: /home/matthew/.pyenv/versions/3.7.0/bin/python3
3.6.8: /usr/bin/python3.6
3.6.8: /usr/bin/python3.6m
3.6.5: /home/matthew/.pyenv/versions/3.6.5/bin/python3.6m
3.6.5: /home/matthew/.pyenv/versions/3.6.5/bin/python3
3.6.4: /home/matthew/.pyenv/versions/3.6.4/bin/python3.6m
3.6.4: /home/matthew/.pyenv/versions/3.6.4/bin/python3
3.6.2: /home/matthew/.pyenv/versions/kafka-python/bin/python3
3.6.2: /home/matthew/.pyenv/versions/3.6.2/bin/python3.6m
3.6.1: /home/matthew/.pyenv/versions/cleaner/bin/python3
3.6.1: /home/matthew/.pyenv/versions/3.6.1/bin/python3.6m
3.6.0: /home/matthew/.pyenv/versions/pg-es-venv/bin/python3
3.6.0: /home/matthew/.pyenv/versions/3.6.0/bin/python3.6m
3.5.4: /home/matthew/.pyenv/versions/3.5.4/bin/python3.5m
3.5.4: /home/matthew/.pyenv/versions/3.5.4/bin/python3
3.4.2: /home/matthew/.pyenv/versions/3.4.2/bin/python3.4m
3.4.2: /home/matthew/.pyenv/versions/3.4.2/bin/python3
2.7.15: /usr/bin/python2
2.7.13: /home/matthew/.pyenv/versions/2.7.13/bin/python2.7

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.6.8',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.15.0-23-generic',
 'platform_system': 'Linux',
 'platform_version': '#25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018',
 'python_full_version': '3.6.8',
 'python_version': '3.6',
 'sys_platform': 'linux'}

System environment variables:

CLUTTER_IM_MODULE
COLORTERM
DBUS_SESSION_BUS_ADDRESS
DEFAULTS_PATH
DERBY_HOME
DESKTOP_SESSION
DISPLAY
GDMSESSION
GJS_DEBUG_OUTPUT
GJS_DEBUG_TOPICS
GNOME_DESKTOP_SESSION_ID
GNOME_SHELL_SESSION_MODE
GNOME_TERMINAL_SCREEN
GNOME_TERMINAL_SERVICE
GPG_AGENT_INFO
GTK2_MODULES
GTK_IM_MODULE
GTK_MODULES
HOME
IM_CONFIG_PHASE
J2REDIR
J2SDKDIR
JAVA_HOME
LANG
LANGUAGE
LOGNAME
MANDATORY_PATH
PATH
POWERLINE_COMMAND
PWD
QT4_IM_MODULE
QT_ACCESSIBILITY
QT_IM_MODULE
QT_QPA_PLATFORMTHEME
SESSION_MANAGER
SHELL
SHLVL
SSH_AGENT_PID
SSH_AUTH_SOCK
S_COLORS
TERM
TEXTDOMAIN
TEXTDOMAINDIR
TMUX
TMUX_PANE
TMUX_PLUGIN_MANAGER_PATH
USER
USERNAME
VTE_VERSION
WINDOWPATH
XAUTHORITY
XDG_CONFIG_DIRS
XDG_CURRENT_DESKTOP
XDG_DATA_DIRS
XDG_MENU_PREFIX
XDG_RUNTIME_DIR
XDG_SEAT
XDG_SESSION_DESKTOP
XDG_SESSION_ID
XDG_SESSION_TYPE
XDG_VTNR
XMODIFIERS
OLDPWD
ZSH
PAGER
LESS
LSCOLORS
LS_COLORS
PYENV_ROOT
PYENV_SHELL
PYENV_VIRTUALENV_INIT
KEYTIMEOUT
VISUAL
EDITOR
SVN_EDITOR
GIT_EDITOR
UBUNTU_MENUPROXY
FZF_DEFAULT_OPTS
FZF_DEFAULT_COMMAND
VIRTUAL_ENV_DISABLE_PROMPT
ANTIBODY_HOME
ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE
SDKMAN_DIR
SDKMAN_PLATFORM
SDKMAN_VERSION
SDKMAN_CANDIDATES_API
SDKMAN_CANDIDATES_DIR
GRADLE_HOME
LC_ALL
LC_CTYPE
DEFAULT_USER
_
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_SHIMS_BASE_MODULE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:
Debug–specific environment variables:

PATH: /home/matthew/.pyenv/plugins/pyenv-virtualenv/shims:/home/matthew/.pyenv/shims:/home/matthew/.pyenv/bin:/home/matthew/.sdkman/candidates/gradle/current/bin:/home/matthew/.pyenv/plugins/pyenv-virtualenv/shims:/home/matthew/.pyenv/shims:/home/matthew/.pyenv/bin:/home/matthew/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/matthew/.gem/ruby/1.9.1/bin:/home/matthew/.gem/ruby/2.3.0/bin:/home/matthew/.gem/ruby/2.5.0/bin:/home/matthew/.antibody/https-COLON--SLASH--SLASH-gitlab.com-SLASH-matthewfranglen-SLASH-docker-go/bin:/home/matthew/.antibody/https-COLON--SLASH--SLASH-gitlab.com-SLASH-matthewfranglen-SLASH-format-python:/home/matthew/.antibody/https-COLON--SLASH--SLASH-gitlab.com-SLASH-matthewfranglen-SLASH-git-stashes:/home/matthew/.antibody/https-COLON--SLASH--SLASH-gitlab.com-SLASH-matthewfranglen-SLASH-random:/home/matthew/.antibody/https-COLON--SLASH--SLASH-github.com-SLASH-matthewfranglen-SLASH-gitflow-avh:/home/matthew/.fzf/bin
SHELL: /bin/zsh
EDITOR: vim
LANG: en_GB.UTF-8
PWD: /home/matthew/test/pipenv-constraint-failure

Contents of Pipfile ('/home/matthew/tmp/pipenv-constraint-failure/Pipfile'):
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
docker-compose = "*"

[packages]
elasticsearch = "*"

[requires]
python_version = "3.7"

Contents of Pipfile.lock ('/home/matthew/tmp/pipenv-constraint-failure/Pipfile.lock'):
{
    "_meta": {
        "hash": {
            "sha256": "417b5705ec1be0f90a9d402b9fe556c8d94f8c706b7d65ce17eb9ed03d16be6f"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.7"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "elasticsearch": {
            "hashes": [
                "sha256:1ec2ed8ff9994a0b0961081f053c90819696c0d03da204b61b79d416606dd055",
                "sha256:d9eda8d9696f55d7d394ade625a262985d7af762c0b9305b73d421dace41c4e7"
            ],
            "index": "pypi",
            "version": "==7.0.4"
        },
        "urllib3": {
            "hashes": [
                "sha256:b246607a25ac80bedac05c6f282e3cdaf3afb65420fd024ac94435cabe6e18d1",
                "sha256:dbe59173209418ae49d485b87d1681aefa36252ee85884c31346debd19463232"
            ],
            "version": "==1.25.3"
        }
    },
    "develop": {
        "asn1crypto": {
            "hashes": [
                "sha256:2f1adbb7546ed199e3c90ef23ec95c5cf3585bac7d11fb7eb562a3fe89c64e87",
                "sha256:9d5c20441baf0cb60a4ac34cc447c6c189024b6b4c6cd7877034f4965c464e49"
            ],
            "version": "==0.24.0"
        },
        "bcrypt": {
            "hashes": [
                "sha256:0258f143f3de96b7c14f762c770f5fc56ccd72f8a1857a451c1cd9a655d9ac89",
                "sha256:0b0069c752ec14172c5f78208f1863d7ad6755a6fae6fe76ec2c80d13be41e42",
                "sha256:19a4b72a6ae5bb467fea018b825f0a7d917789bcfe893e53f15c92805d187294",
                "sha256:5432dd7b34107ae8ed6c10a71b4397f1c853bd39a4d6ffa7e35f40584cffd161",
                "sha256:69361315039878c0680be456640f8705d76cb4a3a3fe1e057e0f261b74be4b31",
                "sha256:6fe49a60b25b584e2f4ef175b29d3a83ba63b3a4df1b4c0605b826668d1b6be5",
                "sha256:74a015102e877d0ccd02cdeaa18b32aa7273746914a6c5d0456dd442cb65b99c",
                "sha256:763669a367869786bb4c8fcf731f4175775a5b43f070f50f46f0b59da45375d0",
                "sha256:8b10acde4e1919d6015e1df86d4c217d3b5b01bb7744c36113ea43d529e1c3de",
                "sha256:9fe92406c857409b70a38729dbdf6578caf9228de0aef5bc44f859ffe971a39e",
                "sha256:a190f2a5dbbdbff4b74e3103cef44344bc30e61255beb27310e2aec407766052",
                "sha256:a595c12c618119255c90deb4b046e1ca3bcfad64667c43d1166f2b04bc72db09",
                "sha256:c9457fa5c121e94a58d6505cadca8bed1c64444b83b3204928a866ca2e599105",
                "sha256:cb93f6b2ab0f6853550b74e051d297c27a638719753eb9ff66d1e4072be67133",
                "sha256:d7bdc26475679dd073ba0ed2766445bb5b20ca4793ca0db32b399dccc6bc84b7",
                "sha256:ff032765bb8716d9387fd5376d987a937254b0619eff0972779515b5c98820bc"
            ],
            "version": "==3.1.7"
        },
        "cached-property": {
            "hashes": [
                "sha256:3a026f1a54135677e7da5ce819b0c690f156f37976f3e30c5430740725203d7f",
                "sha256:9217a59f14a5682da7c4b8829deadbfc194ac22e9908ccf7c8820234e80a1504"
            ],
            "version": "==1.5.1"
        },
        "certifi": {
            "hashes": [
                "sha256:046832c04d4e752f37383b628bc601a7ea7211496b4638f6514d0e5b9acc4939",
                "sha256:945e3ba63a0b9f577b1395204e13c3a231f9bc0223888be653286534e5873695"
            ],
            "version": "==2019.6.16"
        },
        "cffi": {
            "hashes": [
                "sha256:041c81822e9f84b1d9c401182e174996f0bae9991f33725d059b771744290774",
                "sha256:046ef9a22f5d3eed06334d01b1e836977eeef500d9b78e9ef693f9380ad0b83d",
                "sha256:066bc4c7895c91812eff46f4b1c285220947d4aa46fa0a2651ff85f2afae9c90",
                "sha256:066c7ff148ae33040c01058662d6752fd73fbc8e64787229ea8498c7d7f4041b",
                "sha256:2444d0c61f03dcd26dbf7600cf64354376ee579acad77aef459e34efcb438c63",
                "sha256:300832850b8f7967e278870c5d51e3819b9aad8f0a2c8dbe39ab11f119237f45",
                "sha256:34c77afe85b6b9e967bd8154e3855e847b70ca42043db6ad17f26899a3df1b25",
                "sha256:46de5fa00f7ac09f020729148ff632819649b3e05a007d286242c4882f7b1dc3",
                "sha256:4aa8ee7ba27c472d429b980c51e714a24f47ca296d53f4d7868075b175866f4b",
                "sha256:4d0004eb4351e35ed950c14c11e734182591465a33e960a4ab5e8d4f04d72647",
                "sha256:4e3d3f31a1e202b0f5a35ba3bc4eb41e2fc2b11c1eff38b362de710bcffb5016",
                "sha256:50bec6d35e6b1aaeb17f7c4e2b9374ebf95a8975d57863546fa83e8d31bdb8c4",
                "sha256:55cad9a6df1e2a1d62063f79d0881a414a906a6962bc160ac968cc03ed3efcfb",
                "sha256:5662ad4e4e84f1eaa8efce5da695c5d2e229c563f9d5ce5b0113f71321bcf753",
                "sha256:59b4dc008f98fc6ee2bb4fd7fc786a8d70000d058c2bbe2698275bc53a8d3fa7",
                "sha256:73e1ffefe05e4ccd7bcea61af76f36077b914f92b76f95ccf00b0c1b9186f3f9",
                "sha256:a1f0fd46eba2d71ce1589f7e50a9e2ffaeb739fb2c11e8192aa2b45d5f6cc41f",
                "sha256:a2e85dc204556657661051ff4bab75a84e968669765c8a2cd425918699c3d0e8",
                "sha256:a5457d47dfff24882a21492e5815f891c0ca35fefae8aa742c6c263dac16ef1f",
                "sha256:a8dccd61d52a8dae4a825cdbb7735da530179fea472903eb871a5513b5abbfdc",
                "sha256:ae61af521ed676cf16ae94f30fe202781a38d7178b6b4ab622e4eec8cefaff42",
                "sha256:b012a5edb48288f77a63dba0840c92d0504aa215612da4541b7b42d849bc83a3",
                "sha256:d2c5cfa536227f57f97c92ac30c8109688ace8fa4ac086d19d0af47d134e2909",
                "sha256:d42b5796e20aacc9d15e66befb7a345454eef794fdb0737d1af593447c6c8f45",
                "sha256:dee54f5d30d775f525894d67b1495625dd9322945e7fee00731952e0368ff42d",
                "sha256:e070535507bd6aa07124258171be2ee8dfc19119c28ca94c9dfb7efd23564512",
                "sha256:e1ff2748c84d97b065cc95429814cdba39bcbd77c9c85c89344b317dc0d9cbff",
                "sha256:ed851c75d1e0e043cbf5ca9a8e1b13c4c90f3fbd863dacb01c0808e2b5204201"
            ],
            "version": "==1.12.3"
        },
        "chardet": {
            "hashes": [
                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
            ],
            "version": "==3.0.4"
        },
        "cryptography": {
            "hashes": [
                "sha256:24b61e5fcb506424d3ec4e18bca995833839bf13c59fc43e530e488f28d46b8c",
                "sha256:25dd1581a183e9e7a806fe0543f485103232f940fcfc301db65e630512cce643",
                "sha256:3452bba7c21c69f2df772762be0066c7ed5dc65df494a1d53a58b683a83e1216",
                "sha256:41a0be220dd1ed9e998f5891948306eb8c812b512dc398e5a01846d855050799",
                "sha256:5751d8a11b956fbfa314f6553d186b94aa70fdb03d8a4d4f1c82dcacf0cbe28a",
                "sha256:5f61c7d749048fa6e3322258b4263463bfccefecb0dd731b6561cb617a1d9bb9",
                "sha256:72e24c521fa2106f19623a3851e9f89ddfdeb9ac63871c7643790f872a305dfc",
                "sha256:7b97ae6ef5cba2e3bb14256625423413d5ce8d1abb91d4f29b6d1a081da765f8",
                "sha256:961e886d8a3590fd2c723cf07be14e2a91cf53c25f02435c04d39e90780e3b53",
                "sha256:96d8473848e984184b6728e2c9d391482008646276c3ff084a1bd89e15ff53a1",
                "sha256:ae536da50c7ad1e002c3eee101871d93abdc90d9c5f651818450a0d3af718609",
                "sha256:b0db0cecf396033abb4a93c95d1602f268b3a68bb0a9cc06a7cff587bb9a7292",
                "sha256:cfee9164954c186b191b91d4193989ca994703b2fff406f71cf454a2d3c7327e",
                "sha256:e6347742ac8f35ded4a46ff835c60e68c22a536a8ae5c4422966d06946b6d4c6",
                "sha256:f27d93f0139a3c056172ebb5d4f9056e770fdf0206c2f422ff2ebbad142e09ed",
                "sha256:f57b76e46a58b63d1c6375017f4564a28f19a5ca912691fd2e4261b3414b618d"
            ],
            "version": "==2.7"
        },
        "docker": {
            "extras": [
                "ssh"
            ],
            "hashes": [
                "sha256:2434b396e616a5ef682fbf80e04839a59e8b81880ece5662c33dff34b8863519",
                "sha256:a062a9f82dff025f79c2097c46f49f143f8898274db7e66041f78cafee66b962"
            ],
            "version": "==3.7.3"
        },
        "docker-compose": {
            "hashes": [
                "sha256:59babecccf76c3c9d796f69b463f3ad5410d03d69e074b299bf3bf4b222aaf5c",
                "sha256:a5d58e974fd717e24b0dda6669a46bc03548d9023ef38d965acdc32d4d5fa753"
            ],
            "index": "pypi",
            "version": "==1.24.1"
        },
        "docker-pycreds": {
            "hashes": [
                "sha256:6ce3270bcaf404cc4c3e27e4b6c70d3521deae82fb508767870fdbf772d584d4",
                "sha256:7266112468627868005106ec19cd0d722702d2b7d5912a28e19b826c3d37af49"
            ],
            "version": "==0.4.0"
        },
        "dockerpty": {
            "hashes": [
                "sha256:69a9d69d573a0daa31bcd1c0774eeed5c15c295fe719c61aca550ed1393156ce"
            ],
            "version": "==0.4.1"
        },
        "docopt": {
            "hashes": [
                "sha256:49b3a825280bd66b3aa83585ef59c4a8c82f2c8a522dbe754a8bc8d08c85c491"
            ],
            "version": "==0.6.2"
        },
        "idna": {
            "hashes": [
                "sha256:156a6814fb5ac1fc6850fb002e0852d56c0c8d2531923a51032d1b70760e186e",
                "sha256:684a38a6f903c1d71d6d5fac066b58d7768af4de2b832e426ec79c30daa94a16"
            ],
            "version": "==2.7"
        },
        "jsonschema": {
            "hashes": [
                "sha256:000e68abd33c972a5248544925a0cae7d1125f9bf6c58280d37546b946769a08",
                "sha256:6ff5f3180870836cae40f06fa10419f557208175f13ad7bc26caa77beb1f6e02"
            ],
            "version": "==2.6.0"
        },
        "paramiko": {
            "hashes": [
                "sha256:99f0179bdc176281d21961a003ffdb2ec369daac1a1007241f53374e376576cf",
                "sha256:f4b2edfa0d226b70bd4ca31ea7e389325990283da23465d572ed1f70a7583041"
            ],
            "version": "==2.6.0"
        },
        "pycparser": {
            "hashes": [
                "sha256:a988718abfad80b6b157acce7bf130a30876d27603738ac39f140993246b25b3"
            ],
            "version": "==2.19"
        },
        "pynacl": {
            "hashes": [
                "sha256:05c26f93964373fc0abe332676cb6735f0ecad27711035b9472751faa8521255",
                "sha256:0c6100edd16fefd1557da078c7a31e7b7d7a52ce39fdca2bec29d4f7b6e7600c",
                "sha256:0d0a8171a68edf51add1e73d2159c4bc19fc0718e79dec51166e940856c2f28e",
                "sha256:1c780712b206317a746ace34c209b8c29dbfd841dfbc02aa27f2084dd3db77ae",
                "sha256:2424c8b9f41aa65bbdbd7a64e73a7450ebb4aa9ddedc6a081e7afcc4c97f7621",
                "sha256:2d23c04e8d709444220557ae48ed01f3f1086439f12dbf11976e849a4926db56",
                "sha256:30f36a9c70450c7878053fa1344aca0145fd47d845270b43a7ee9192a051bf39",
                "sha256:37aa336a317209f1bb099ad177fef0da45be36a2aa664507c5d72015f956c310",
                "sha256:4943decfc5b905748f0756fdd99d4f9498d7064815c4cf3643820c9028b711d1",
                "sha256:57ef38a65056e7800859e5ba9e6091053cd06e1038983016effaffe0efcd594a",
                "sha256:5bd61e9b44c543016ce1f6aef48606280e45f892a928ca7068fba30021e9b786",
                "sha256:6482d3017a0c0327a49dddc8bd1074cc730d45db2ccb09c3bac1f8f32d1eb61b",
                "sha256:7d3ce02c0784b7cbcc771a2da6ea51f87e8716004512493a2b69016326301c3b",
                "sha256:a14e499c0f5955dcc3991f785f3f8e2130ed504fa3a7f44009ff458ad6bdd17f",
                "sha256:a39f54ccbcd2757d1d63b0ec00a00980c0b382c62865b61a505163943624ab20",
                "sha256:aabb0c5232910a20eec8563503c153a8e78bbf5459490c49ab31f6adf3f3a415",
                "sha256:bd4ecb473a96ad0f90c20acba4f0bf0df91a4e03a1f4dd6a4bdc9ca75aa3a715",
                "sha256:e2da3c13307eac601f3de04887624939aca8ee3c9488a0bb0eca4fb9401fc6b1",
                "sha256:f67814c38162f4deb31f68d590771a29d5ae3b1bd64b75cf232308e5c74777e0"
            ],
            "version": "==1.3.0"
        },
        "pyyaml": {
            "hashes": [
                "sha256:3d7da3009c0f3e783b2c873687652d83b1bbfd5c88e9813fb7e5b03c0dd3108b",
                "sha256:3ef3092145e9b70e3ddd2c7ad59bdd0252a94dfe3949721633e41344de00a6bf",
                "sha256:40c71b8e076d0550b2e6380bada1f1cd1017b882f7e16f09a65be98e017f211a",
                "sha256:558dd60b890ba8fd982e05941927a3911dc409a63dcb8b634feaa0cda69330d3",
                "sha256:a7c28b45d9f99102fa092bb213aa12e0aaf9a6a1f5e395d36166639c1f96c3a1",
                "sha256:aa7dd4a6a427aed7df6fb7f08a580d68d9b118d90310374716ae90b710280af1",
                "sha256:bc558586e6045763782014934bfaf39d48b8ae85a2713117d16c39864085c613",
                "sha256:d46d7982b62e0729ad0175a9bc7e10a566fc07b224d2c79fafb5e032727eaa04",
                "sha256:d5eef459e30b09f5a098b9cea68bebfeb268697f78d647bd255a085371ac7f3f",
                "sha256:e01d3203230e1786cd91ccfdc8f8454c8069c91bee3962ad93b87a4b2860f537",
                "sha256:e170a9e6fcfd19021dd29845af83bb79236068bf5fd4df3327c1be18182b2531"
            ],
            "version": "==3.13"
        },
        "requests": {
            "hashes": [
                "sha256:65b3a120e4329e33c9889db89c80976c5272f56ea92d3e74da8a463992e3ff54",
                "sha256:ea881206e59f41dbd0bd445437d792e43906703fff75ca8ff43ccdb11f33f263"
            ],
            "version": "==2.20.1"
        },
        "six": {
            "hashes": [
                "sha256:3350809f0555b11f552448330d0b52d5f24c91a322ea4a15ef22629740f3761c",
                "sha256:d16a0141ec1a18405cd4ce8b4613101da75da0e9a7aec5bdd4fa804d0e0eba73"
            ],
            "version": "==1.12.0"
        },
        "texttable": {
            "hashes": [
                "sha256:119041773ff03596b56392532f9315cb3a3116e404fd6f36e76a7dc088d95c79"
            ],
            "version": "==0.9.1"
        },
        "urllib3": {
            "hashes": [
                "sha256:b246607a25ac80bedac05c6f282e3cdaf3afb65420fd024ac94435cabe6e18d1",
                "sha256:dbe59173209418ae49d485b87d1681aefa36252ee85884c31346debd19463232"
            ],
            "version": "==1.25.3"
        },
        "websocket-client": {
            "hashes": [
                "sha256:1151d5fb3a62dc129164292e1227655e4bbc5dd5340a5165dfae61128ec50aa9",
                "sha256:1fd5520878b68b84b5748bb30e592b10d0a91529d5383f74f4964e72b297fd3a"
            ],
            "version": "==0.56.0"
        }
    }
}

From reading the locking output it appears to correctly establish the urllib3 constraint during the first section (presumably installing the dev-packages) and then discards them when establishing constraints during the second section.
I can understand the desire to have a single Pipfile.lock which supports only installing the packages (and not the dev packages) while maintaining a single set of dependency versions, however this breaks things. I found this when I installed twine as a dev package and it was broken due to the urllib3 dependency version. I had to use pip within the virtualenv to force downgrade urllib3.

@matthewfranglen What is your proposal for this situation?
people only want to install default packages but it fails because there are conflicting dependencies between develop dependencies.

In this situation there is a resolution available which is to use the urllib3 library with the intersection of the constraints (i.e. >=1.21.1,<1.25).
I feel that the guiding principle here should be that:

Installing just the regular packages works
Installing the regular packages and the dev packages works

The dev packages were added at some point by the author of whatever the project is so at that point it would be appropriate to check that they can be satisfied (and error appropriately if not). If the dev packages + regular packages work then the regular packages will also work on their own.
Otherwise in order to use the dev packages you need to hoist the constraints to the regular packages where they do not belong, which is a time consuming and opaque process.

There are a number of issues tracking this same problem in the backlog -- I am proposing we leave the default behavior of default overrides develop, but provide an option that can be added to the [pipenv] section of the Pipfile to not use the constraints on the develop group.


[UIExplorer] fix gratuitous app crash

Now it fails

Test plan (required)
UIExplorer

Oh, I see, the extrapolate prop was in the wrong object.
@facebook-github-bot shipit


Output in version 1.1.1

In the new version, I can see this being printed though my test cases:
Flask Allowed Hosts -> All hosts are allowed, request was permitted.

I did not switch on debug information.

You can enable debug mode by setting the ALLOWED_HOSTS_DEBUG environment variable to True:
export ALLOWED_HOSTS_DEBUG="True"
This will print helpful debug messages to the console.

I did not set that but it still prints it. Is this based on the general debug flag?
I would like to not see it by default.

fixed by: https://github.com/riad-azz/flask-allowed-hosts/pull/7

adjusted to make sure debug mode is only enabled when set to True as documented : https://github.com/riad-azz/flask-allowed-hosts/commit/243a6166c96f4a17c215cc75b03cf6ba931f2da7


Negative results

I'm using the lassosum.pipeline / validate / subset / validate strategy of the README (splitting the test set in 2).
I'm getting v2$best.validation.result equals to -0.491. And AUC(v2$best.pgs, v2$pheno - 1) equals to 0.205.
Is this normal? Should I just take the opposite?

Note that the binary phenotype is coded as 1/2 as in standard PLINK format.

That's not normal. However, I am unable to determine what might have gone wrong based on what you reported. If it's ok, can you PM me your dataset and the exact command you used?

I wanted to make a reproducible example with fake data but I'm getting a new error:
Coordinating summary stats with reference panel...
Splitting genome by LD blocks ...
Running lassosum ...
s =  0.2
Error in lassosum(cor = cor2, bfile = ref.bfile, shrink = s, extract = ref.extract,  :
  !any(is.na(cor)) is not TRUE

I've no missing value in cor...

The code I wanted to use:
# devtools::install_github("privefl/bigsnpr")
library(bigsnpr)

set.seed(1)
N <- 1000; M <- 1e4
snp <- snp_fake(N, M)
snp$genotypes[] <- sample(0:2, size = N * M, replace = TRUE)
snp$fam$affection <- sample(1:2, N, TRUE)
snp$map$physical.pos <- seq(2, 2e8, length.out = M)

bed <- snp_writeBed(snp, tempfile(fileext = ".bed"))
rds <- snp_readBed(bed, sub("\\.bed$", "", bed))

# devtools::install_github("tshmak/lassosum")
snp <- snp_attach(rds)
G <- snp$genotypes
CHR <- snp$map$chromosome
POS <- snp$map$physical.pos
A1 <- snp$map$allele1
A2 <- snp$map$allele2
y <- snp$fam$affection - 1

set.seed(1)
ind.train <- sort(sample(nrow(G), size = N * 0.6))
ind.test <- setdiff(rows_along(G), ind.train)
ind.test.split <- split(ind.test, sample(1:2, length(ind.test), TRUE))

gwas <- big_univLogReg(G, y[ind.train], ind.train)
hist(pval <- predict(gwas, log10 = FALSE))

library(lassosum)
bed2 <- snp_writeBed(snp, tempfile(fileext = ".bed"),
                     ind.row = ind.test.split[[1]])
bed3 <- snp_writeBed(snp, tempfile(fileext = ".bed"),
                     ind.row = ind.test.split[[2]])
cor <- p2cor(p = pval, n = length(ind.train), sign = gwas$estim)
out <- lassosum.pipeline(cor = cor, chr = CHR, pos = POS, A1 = A1, A2 = A2,
                         test.bfile = sub("\\.bed$", "", bed2),
                         LDblocks = "EUR.hg19")

wv <- validate(out)
out2 <- subset(out, s = v$best.s, lambda = v$best.lambda)
v2 <- validate(out2, test.bfile = sub("\\.bed$", "", bed3))

AUC(v2$best.pgs, v2$pheno - 1)

Thanks for the example. The !any(is.na(cor)) is not TRUE error turned out to be due to the genotypes in your synthetic example being all A/T. These SNPs all got excluded because they were ambiguous. You can get around this by passing the exclude.ambiguous=F option to lassosum.pipeline and also to the second validate command.
I tried it with these options and found that the resulting v$best.validation.result was 0.05, and v2$best.validation.result was 0.007.

I have
> rawToBits(readBin(bed, what = raw(), n = 5)[4:5])
 [1] 00 00 01 01 01 01 00 00 00 00 00 00 01 01 01 01
> snp$genotypes[1:8]
[1] 0 2 2 0 0 0 2 2

In Plink format, 0,1,2 should correspond to the number of A1 alleles (not A2). Therefore the 16 bits you showed there would mean 2 0 0 2 2 2 0 0 to plink, which is opposite to what you had in snp$genotypes[1:8]. Alternatively, you could swap the A1 and A2 when you write out the .bim file. See https://www.cog-genomics.org/plink2/formats#bed for details.

Hum, you may be right. Yet, it is weird to code homoziguous referent by 2...
I'm using the same convention as in package {gaston}.
Otherwise, I could simply swap A1 and A2 when I use lassosum, right?
Last question, what is the difference between $pgs and $best.pgs in the results. The documentation (part Value) does not really match the list I'm getting.

Hi Tim, I also met this problem when calculating PRS using the Type II diabetes summary statistics using T2D_ALL_PRIMARY dataset from:
https://blog.nus.edu.sg/agen/summary-statistics/t2d-2020/
My cor does not contain Na, and I tried to add the exclude.ambiguous option, but both methods do not work. I tried lassosum on other summary statistics and this issue did not happen. May I ask for your help with this? Thank you very much.

It is not clear what  your problem is. There are many possible reasons for having negative results. Please open a new issue and describe exactly what your codes are, what the output is, and what you expect the output to be. Preferably include a reproducible example.

I have the same problem with the Lassosum calculation PRS. I used Low density lipoprotein cholesterol Base Date available on https://humandbs.biosciencedbc.jp/en/hum0014-v21#58qt and Target Date provided by my laboratory. The Quality Control was performed using Tutorial (https://choishingwan.github.io/PRS-Tutorial/base/). But Lassosum gets $best.validation.result equals to -0.0380079. I think it is not a normal situation and something is wrong with my data, but I can not find the mistake.
Could you please help me to find out the problem?

Try reversing all effects.

It works! Thank you very much.


Bugfix/6.4/tdi 38475 api mode update schema

What is the current behavior? (You can also link to an open issue here)
https://jira.talendforge.org/browse/TDI-38475
https://jira.talendforge.org/browse/TDI-38567
What is the new behavior?
On a referenced connection, when changing the connection ApiMode, the UI is updated to reflect the correct parameters on the components.
However, we still have some UI issues with the schema and mappings table on some cases.
A JIRA issue was created for the mapping table refresh has been created (TUP-17495), I will create another issue because when the schema is changed in code not triggered by an event like an after* method, the schema is not correctly updated.
updated: added issue https://jira.talendforge.org/browse/TUP-17509
Please check if the PR fulfills these requirements

[X] The commit message follows Talend standard
[X] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[X] The code coverage on new code >75%
[X] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[X] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: success :star:

Hello @jzhao-talend, can you have a look at these issues  ?
https://jira.talendforge.org/browse/TUP-17495
https://jira.talendforge.org/browse/TUP-17509

Pull request test result: success :star:

About those 2 tup issue:
I also have sure idea about them.
I found your properties refresh tests are called manually.
I think you can add some unit tests to debug the code.
Like what we do for salesforce https://github.com/Talend/components/blob/master/components/components-salesforce/components-salesforce-definition/src/test/java/org/talend/components/salesforce/test/SalesforcePropertiesTest.java#L46
This is more like what operate on studio side.
This need you

change the property value
use PropertiesDynamicMethodHelper call the after/before/...
then check the properties value whether as you expect.

Not sure this can help you or not. At lease you can debug the code

Pull request test result: success :star:

@jzhao-talend : Thanks for the help.
Everything works perfectly in tests. The problem is met in the studio.
I also debugged the studio, and for me it's coming from the studio.

Pull request test result: success :star:

@undx https://jira.talendforge.org/browse/TUP-17509
Maybe this is TCOMP issue, we need consider that how nest properties TMarketoConnectionProperties connection changes triggered the refreshLayout: https://github.com/Talend/components/blob/d61440b46325b102173493922c43f2437ff604ce/components/components-marketo/src/main/java/org/talend/components/marketo/tmarketoinput/TMarketoInputProperties.java#L411 of TMarketoInputProperties

Hi @jzhao-talend,
didn't know about PropertiesDynamicMethodHelper, good to know. 👍
The result is what I've in the studio (schema doesn't match) but in fact, when you change ApiMode you're in the ADVANCED tab of the component and the refreshLayout(Form.ADVANCED) is also triggered (see the log on the TUP issue).
If I trigger this event, the schema match.

yes. when switch the basic/advanced setting. it would call refreshLayout, but it not triggered by APIMode
I also not sure this issue exact for which team.

Pull request test result: success :star:


"Failed to establish protocol: v3" with new reason-scripts app

I created a brand-new ReactReason app using reason-scripts, and opened the folder with VSC, but was greeted by the above error:
Request initialize failed with message: onInitialize: failed to establish protocol v3

If I was to take a wild guess, it'd be because we don't support the new v3 syntax yet? A .merlin file exists, and aside from the more "IDE"-like features its working somewhat, but I wanted to check if perhaps I'd done something incorrectly!
Cheers,
Josh

The v3 here has to do with the version of the protocol it uses to communicate with merlin. I think the only way this should happen is if you somehow have a very old version of ocamlmerlin in your PATH. How do you have your development environment set up?

@freebroccolo Ah, that'd do it! I setup my OCaml environment up yonks ago; I'll give opam upgrade a try and see what happens :) Cheers!

I'll go ahead and close this. Let me know if there's still a problem.


Setting contentType in ResponseSpecification appears to set the request's contentType

During upgrade from 2.3.2 to 3.0.7 I encountered the following issue with this test. No content type specified in request, and expect text/html to be the response content type.
      given().
         header("Accept", ContentType.BINARY.getAcceptHeader()).
      expect().
         statusCode(200).
         contentType(ContentType.HTML).
      when().
         get("...");

RestAssured reports an 415 error (invalid media type) via enableLoggingOfRequestAndResponseIfValidationFails:
Request method:	GET
Request URI:	...
Proxy:			<none>
Request params:	<none>
Query params:	<none>
Form params:	<none>
Path params:	<none>
Headers:		Accept=application/octet-stream
Cookies:		<none>
Multiparts:		<none>
Body:			<none>

HTTP/1.1 415
Content-Type: application/json;charset=UTF-8
Content-Length: 2
Date: ...

{

}

However using Wireshark I am seeing something different -- the contentType request header is set to text/html as well:
Hypertext Transfer Protocol
    GET ... HTTP/1.1\r\n
    Content-Type: text/html\r\n
    Authorization: ...\r\n
    Accept: application/octet-stream\r\n
    Content-Length: 0\r\n
    Host: ...\r\n
    Connection: Keep-Alive\r\n
    User-Agent: Apache-HttpClient/4.4.1 (Java/1.8.0_131)\r\n
    Accept-Encoding: gzip,deflate\r\n
    \r\n

Is this a bug or a behaviour change? This does not happen with the given/when/then syntax.

Looks very similar to #656


Open 100x fewer file handles when doing large-circuit sample streaming

It's kinda dumb that there's one file per shot in a batch. It makes us go close to system file handle limits (forcing number of samples in a batch to be lower than optimal).

While we're on the topic, the whole "write shot to disk" part of code could use refactoring. There need to be more convenient methods that work on entire shots, both transposed and untransposed in memory.

Closing as not important anymore.


Design: Public facing banner for allowing visitors (not logged in) to sign up monthly

Recreating https://github.com/mdn/browser-compat-data/issues/5162 which was created in the wrong repo
Mock-ups:

InVision prototype

Acceptance criteria:

[ ] Developer sign-off: "all required information for engineering to implement solution are documented"
[ ] Kadir sign-off: "all business and user needs have been considered"
[x] Legal sign-off: "all required legal information is included"
[x] User tested: "simple user-tests have been conducted to ensure users will be able to navigate"
[x] Mock-ups are uploaded on Abstract: "all necessary mock-ups and assets are uploaded"

@atopal @malqinneh This is marked as done in the spreadsheet. Are the first 2 AC satisfied?

Yeah, good to go on my end


react table lose input focus on change. V 6.10 - 6.8.6

Describe the bug
Live https://codesandbox.io/s/6l7op9lovr
After input value change, input is losing focus and we cannot type in more than 1 letter. When downgrade to 6.8.6 input is not losing focus after typing in 1 letter
To Reproduce
Steps to reproduce the behavior:

Go to https://codesandbox.io/s/6l7op9lovr website
Click first input
try to write more than 1 letter in input
check that input has lost focus
downgrade to 6.8.6
Click first input
try to write more than 1 letter
notice that it s possible now

I have the same problem.

We are having same issue, Cell components seem to be unmounting and mounting whenever input value changes, which causes lost focus. With previous ver., this did not happened.
https://codesandbox.io/s/reacttable-simple-table-6t7er?fontsize=14

Same here. Took a while to figure this out but luckily downgrade fixed it. I wonder how much will this change in v7

@PeterKottas, v7 is going to be headless, so anything pertaining to markup, or actually rendering components will be in your hands. Please check out the alpha sandbox in the readme to get a feel for what will be possible.

This is a major bug @tannerlinsley. It makes the tables totally unusable (double click is also failing for me because of lost focus).
I think just saying upgrade to v7 is not enough! Let's figure out which commit caused this issue and fix it!

Indeed, it is a major bug.
I would love that! If you can find the bug and fix it, I will merge a PR for it.

@tannerlinsley  I'll take a peak, I do think you should probably revert/publish over v6.10 in the mean time

This could mean removing and breaking a lot of features that people have PR'd in since then. Which version were you thinking?

I'm doing some sleuthing on my end. Here is my best guess as to where the issue may have been introduced:

All the other changes between v6.8.6 and v.6.10 seem unlikely to have caused the issue to me.
You're maybe correct to hold off publishing over v6.10 if people are using the features they've added since. Let's try to find where this issue is arising

Yep. I would rather find the issue and patch it, rather than take a step backwards. It's bad either way: existing users are either having issues with this bug right now, or will have compatibility issues if we reset.

Ok, after playing with it a bit, it appears that the following change breaks double click for me:

I'm not sure if that change also causes the input focus loss that was the original issue filed here, but it definitely breaks double click for me.
@tannerlinsley what was that change meant to do?

Hmm.. This was a long time ago in dev years, but I think React deprecated or discouraged using isReactComponent. We needed a quick way to tell if a component was a class, function, or JSX.
It's likely that if we simply improve that function to handle all of those edge cases we'll be okay.
Not that this is perfect, but here is what we are working with in v7:
export function flexRender(Comp, props) {
  if (typeof Comp === 'function' || typeof Comp === 'object') {
    return <Comp {...props} />
  }
  return Comp
}

Currently, it doesn't handle detecting JSX primitives, so you have to do this: Header: () => Yo, instead of just Header: Yo. I wish it did detect this though.

maybe we can follow the top voted answer here: https://stackoverflow.com/questions/33199959/how-to-detect-a-react-component-vs-a-react-element
?

Hmm... 🤔  https://twitter.com/dan_abramov/status/787739945301635073

It's really the difference between a react component and a react element.
A component is a class or function that has not been  yet, and an element has already been  into an React Element object.

I meant this one: https://stackoverflow.com/a/41658173/2178112

Yep. Those are perfect. We need to incorporate those into the render function for voth v6 and v7.

Would you like to test those out and update the older function? I'll work on the v7 impl.

Okay I put a PR in @tannerlinsley

Merged.

I'll try and get a release out tonight.

@tannerlinsley @tnrich to check if something is react component you should use react-is, or the elementType from prop-types https://github.com/ReactTraining/react-router/issues/6819. Component can be also object in later version of react, not just class/function.

@croraf If you'd like to submit a PR to improve what @tnrich has done in v6, then please do.

Anyone tried ver 6.10.1?
Having this silly colum definition
{
Header: "Pick",
accessor: "name",
Cell: (r: any) => "hello"
}
I'm getting
TypeError: Cannot read property 'isReactComponent' of undefined
isClassComponent
C:/tfs/repos/ecod/app/node_modules/react-table/es/utils.js:263
260 | }
261 |
262 | function isClassComponent(component) {

263 |   return !!(typeof component === 'function' && !!component.prototype.isReactComponent);
264 | }
265 |
266 | function isFunctionComponent(component) {

Works fine with ver 6.10.0

@tannerlinsley has it been released yet? Using 6.10.3 and just faced the same issue. My own workaround here https://github.com/tannerlinsley/react-table/issues/1346#issuecomment-533811901 doesn't really work for me as I need to pass additional data to render function from upper scope.

Issue says closed but I'm still having the same issue.

I have the same issue since v6.9.0.
v6.8.6 works fine.

Still an issue in 6.10.3. This shouldn't be closed

This is still an issue

@Dozalex  @dayanrr91 @peterspliid can you please describe the issue and give steps for reproducing? I think this issue has been fixed for me

@tnrich I just tested on version 6.10.3, and it is still an issue for me
I have a table with a controlled input text field, something like this:
const [data, setData] = useState([ {name: 'Peter'} ])

let columns: Column[] = [
        {
            id: 'name',
            Header: 'Your name',
            accessor: 'name',
            Cell: (row: RowInfo) => (
                <input
                    type="text"
                    value={row.original.name}
                    onChange={e=> setData([ {name: e.target.value} ])}
                />
            )
        }
]
<ReactTable
            data={data}
            columns={columns}
            showPagination={false}
            minRows={0}
        />

@peterspliid have u tried evenfrost's suggestion here:
 #1346 (comment)

@peterspliid have u tried evenfrost's suggestion here:
 #1346 (comment)

It didn't work when I just moved the cell rendering function to a function (inside my functional component), but it worked when I moved it into a useCallback. So I'll do that to 'fix' it.
It wasn't necessary on 6.8.6, so although there now is a workaround, I still think that this is an issue that needs to be fixed.
And Thanks @tareqdayya for the workaround.

Usecallback does not work if you have multiple controlled input fields in the table. I've also try to move the function out of the functional component, which works when testing it, but when it has been built, it stops working. So back to 6.8.6

Usecallback does not work if you have multiple controlled input fields in the table. I've also try to move the function out of the functional component, which works when testing it, but when it has been built, it stops working. So back to 6.8.6

Same here, 6.10.3, 6.8.2, 6.8.6 works fine in dev build, in prod build only version 6.8.6 keeps focus.

I'm facing the same problem! :(
What is the workaround that is working for now? Instead of downgrade of react table?!
Someone know another react component for build table with input columns, thanks

I just tryed for several hours and I couldn't find any workaround for it. At the end I downgraded the react table version and everything was fine by me.

I'm also facing the same issue and after downgrade to 6.8.6 issue remains same

Facing the same issue. I have multiple filters with controlled inputs that receive their values from a Redux store and the focus is lost on every keypress.

As I understood, the problem here is that when you pass the function to the Header it's re-mounted with every change. So, I tried to passing the component and this solved my problem
const Search = <SearchUI onSearch={handleSearchUpdate}/>;

const columns = [
  {
    name: 'Name',
    columns: [
      accessor: 'name',
      id: 'Name',
      width: 200,
      Header: Search,
    ],
  },
];

This lib was completely rewritten for v7. Since v6 is not supported anyways, does it really matter if you keep on using 6.8.6? You are using an outdated version anyways unless you are willing to do a complete rewrite for v7 (which doesn't suffer from this bug).

This lib was completely rewritten for v7. Since v6 is not supported anyways, does it really matter if you keep on using 6.8.6? You are using an outdated version anyways unless you are willing to do a complete rewrite for v7 (which doesn't suffer from this bug).

I'm using 7.0.0 and from what i can tell still have this bug.
It could be because i have a conditional?
...
Cell: ({ cell: { value }, row: { original } }: CellProps<Data>) =>
        editingObjectId !== original.id ? (
          <>{value}</>
        ) : (
          <Input
            name="year"
            value={formData.year}
            onChange={onChange}
            size="sm"
          />
        )

The arrow function is changing in every render, you need to create that cell component once and assign it to a variable. That's React if not javascript basics mate, nothing to do with this lib.

I'm also facing the same issue with versions waht ever you mentioned in the above comments. Please help me on this

I use small hack. Solve is not change columns after change rows.
But, usually, we need access to rows to handle input change.
Therefor we can use small hack - use onChangeRef, and useMemo for columns.
Example:
const onChange = (row: FinancePlanRow, fieldName: keyof FinancePlanRow, value: number) => {
        if (props.onChange) {
            props.onChange(props.rows.map((checkingRow: FinancePlanRow) => {
                if (row.year !== checkingRow.year) {
                    return row;
                }

                return {
                    ...row,
                    [fieldName]: value
                }
            }));
        }
    };

    const onChangeRef = useRef(onChange);
    onChangeRef.current = onChange;

    const columns = useMemo((): Column[] => {
        return [{
            Header: 'EBIDTA',
            accessor: 'ebidta',
            Cell: (cellProps) => {
                return (
                    <NumberInput
                        readonly={props.readonly}
                        value={cellProps.value}
                        name='ebidta'
                        placeholder='0.00'
                        prepend={currency.symbol}
                        withoutBorder={true}
                        onChange={(newValue) => onChangeRef.current(cellProps.row, 'ebidta', newValue)}
                    >{cellProps.value}</NumberInput>
                );
            },
        }];
    }, [currency]);

I have to down grand to 6.8.3 to solve the same problem.

The error is caused by the use of useState, if you give a value from the input to a function, the problem is solved, but you need to keep your values in a variable instead of useState.

I'm facing the same issue, does someone here know how to solve it?


Rename to @react-native-community/peek-and-pop

Hey! 👋
While this package is not released to the public, how about renaming it to: @react-native-community/peek-and-pop? So it corresponds nicely with other community libs.
If you think this is good idea, would be also nice to change the repo address to be https://github.com/react-native-community/peek-and-pop (without redundant react-native)

dope

@satya164 make me admin pls xD


Update Story_Writing_with_Prompt_Chaining.ipynb

typo fix

Hi, please sign the CLA so we can merge this. Thanks!

Hi, please sign the CLA so we can merge this. Thanks!

Done. Thank you sir

Hello Sir Daoust.I think I already have? Is there a mistake?Younes BrahimiSent from my iPhoneOn Jun 4, 2024, at 12:06 PM, Mark Daoust @.***> wrote:
@MarkDaoust approved this pull request.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Yeah, it just needed a refresh. Thanks!

Thank you for the promptness, sir. I realize its a small typo and not a big
contribution but I will keep my eyes on anything better I can contribute,
thank you for keeping this repo alive
Younes Brahimi
On Wed, Jun 5, 2024 at 1:31 PM Mark Daoust @.***> wrote:

Merged #169 https://github.com/google-gemini/cookbook/pull/169 into
main.
—
Reply to this email directly, view it on GitHub
https://github.com/google-gemini/cookbook/pull/169#event-13055028740,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKK7QTARS4WFPVQM6HQR6PTZF5DNVAVCNFSM6AAAAABICRS6QSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGA2TKMBSHA3TIMA
.
You are receiving this because you authored the thread.Message ID:
@.***>


iOS Privacy manifest

Hello 👋
Since recently apple requires a privacy manifest for every app which is accessing a set of sensitive apis/data
https://developer.apple.com/documentation/bundleresources/privacy_manifest_files
Are there any plans to add this to this project?
Or does anyone know which entries would be necessary for this dependency in the manifest file?

Hello and thanks for asking,
As far as I can tell, you don't need a manifest. This package isn't using a 3rd party SDK.
Thank you 🙂

Thanks for the quick answer! Is it also not using any of the specified API's itself?

Thanks for the quick answer! Is it also not using any of the specified API's itself?

which apis do you have in mind?

I could imagine a dependency such as this one, might be (indirectly) using the FiletimeStamp or DiskSpace APIs as described in
https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

I'm not aware of the module using such apis :)


Accordion naming convention?

Description

Any opinions on Accordion often being used with only one Accordion.Item? Today we require that Accordion.Item is always wrapped in a grouping component, but can it occasionally not be a group? :relaxed: See other systems operate with slightly different solutions; some call it Collapsible or Expandable so it is less related to it being in a group context.
And, there is currently no way to set that only one should be open at a time - all Accordion.Items can be opened and closed independently of each other, but maybe that is the intention? :relaxed:
Hover behind chevron: this is a design choice - marked that the designers in the Norwegian Food Safety Authority were confused by whether it was a UU requirement, but thoughts about hoover should be kept on only the chevron, or possibly the whole field?

Feedback from @Thunear :

I am often uses accordion with only 1 item on several different websites in the Digdir universe e.g. in the table of contents.
Will create an admin interface in the near future where I want only 1 accordion item in the left menu to be open at a time. Should perhaps be part of the component?
Hover on Chevron feels a bit weird, we should consider moving hover to the entire surface.

Response from @eirikbacker:
Agree - then think that Expandable is perhaps a better naming convention, as Accordion gives the expectation of grouping and one open at a time. I also think that Expandable can be used without any wrapper around it - it is entirely possible to get rounded edges etc. with pure CSS that looks for the previous and next element, so that:

Some text before

<Expandable>...<Expandable>
<Expandable>...<Expandable>

Some text after

will "connect with each other" and run as a group, while

Some text before

<Expandable>...<Expandable>

Some text between

<Expandable>...<Expandable>

Some text after

rendered separately.
The only annoying thing is that you then have to color each Expandable:

Some text before

<Expandable color="brand1">...<Expandable>
<Expandable color="brand1">...<Expandable>

Some text after

Alternatively, we can offer an Expandable.Group to have a quick way to wrap everyone, but that it is optional. It can be nice, but also a little assessment of how much we should do for people, because they will anyway often loop over content when they generate such groupings, and then they can put props there immediately (a bit the same as we landed on in ToggleGroup).
Regarding one open Expandable at a time; If we implement on top of native , we can offer name="..." to group - when several Expandables have the same name, they are automatically linked together - in exactly the same way as input type="radio" works :relaxed :

Related to https://github.com/digdir/designsystemet/pull/2363

ARIA skiller mellom "Accordion" og "Disclosure": https://www.w3.org/WAI/ARIA/apg/patterns/

...og HTML kaller det details - "the details disclosure element"
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
Se også første notis fra W3C spesifikasjonen: https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element:the-details-element-2

If anything, I suggest going for Collapsible, if we don't want to use Accordion. Could also just use the native name for this, which I feel is the best option.

it is entirely possible to get rounded edges etc. with pure CSS that looks for the previous and next element, so that:
Yes, but what if the accordion is in a layout that adds gap between elements? We can't ensure that we can remove the spacing.
I suggest we still have a *.Group, so remove any confusion nad possible issues.

Agreed ☺ Like the .Group, and both Collapsible and Expandable are good alternatives in my opintion

Why not call the Collapsible/Expandable for Details since we are using the details element?
Thinking out loud here:
For single use:

   // or just ?
  …

Now, if you want it to act like an Accordion
<Accordion>

</Accordion>

What do you guys think?

That could work 🙌 It correlates nicely with details / u-datails for HTML-users as well.
I think we might want Details.Group though?
Just a thought then; should Accordion also affect the behavior or only design?
In pure HTML, if the user wants only one details open at the time, they should add matching name to all  elements - aka. the "Accordion" wrapper does nothing to change behavior, it only affects design.
In React though, we can use context to add single/multiple open-at-the-time logic to Accordion: <Accordion multiple> vs <Accordion>, but this would then be a deviation between React/HTML. Also; one open-at-the-time should be avoided, so maybe it is okay to require actually setting name in React as well?

That could work 🙌 It correlates nicely with details / u-datails for HTML-users as well. I think we might want Details.Group though? Just a thought then;

What would the Details.Group do?
We have no .Group sub-components now.
We moved away from .Group on Checkbox and Radio in favour of hooks.
First though here is we need to keep consistency with component usage/api.

should Accordion also
affect the behavior or only design? In pure HTML, if the user wants only one details open at the time, they should add matching name to all  elements - aka. the "Accordion" wrapper does nothing to change behavior, it only affects design.
In React though, we can use context to add single/multiple open-at-the-time logic to Accordion: <Accordion multiple> vs <Accordion>, but this would then be a deviation between React/HTML. Also; one open-at-the-time should be avoided, so maybe it is okay to require actually setting name in React as well?

Yeah, my though aswell. Accordion is just visual sugar and we expect people to use the "native" Details the way its meant to. If we want to provide some more DX, maybe a useAccordion hook, the same way we have for useRadioGroup which applies name on Radio.
Suggest we first try the most simplest approach, and then we can see how the DX feels and iterate on that.

Meeting 22.11.2024 with @eirikbacker @Febakke @mimarz
We decided to try the following in regards to Accordion.

New component, Details and Details.Summary

This component reflects the native  and  element

Accordion will be removed in favour for composition of Details and Card

The only thing Accordion really did was a div with border and rounded corners around a list of  elements
Accordion without border can be achieved by just listing Details components

Accordion.Content will be removed and styling moved to Details

Animation might not work on some browsers but thats an okay tradeoff than having a superfluous Details.Content

Add stories to both Card and Details on composing them to make them behave like an accordion, with use of name

New Details component

  …

New approach for equivalent <Accordion>
<>

</>

New approach for equivalent <Accordion border>
<Card>

</Card>


Bounty problems

Quite often i don get my bounty removed when killing the last witness either in space or on the ground, its lead to some large chunks of the game being locked off and having to reload earlier saves and just not do that mission, it also makes the crimson fleet mission basically useless

Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
Yes
Reproduction Steps
get a bounty

So after more testing i have found it seems to be when there are multiple targets and you get the higer bounty from killing them that it doesnt go away, for example if i go to kill a crimson fleet ship, and theres only 1 i will get 650 bounty for attacking which is then removed on death, however if there are 2+ i get the 15k bounty from killing them both and it persists even after both ships have been destroyed, this is the same with other factions.
on the ground it appears the same, if you kill a single person with no witnesses apart from that person the bounty goes, but if you ran through a POI killing all the pirates you end up with a huge bounty at the end even though no witnesses remain


plugin type="calico" failed (delete): error getting ClusterInformation: connection is unauthorized: Unauthorized

Hello, I have deployed a MicroK8s cluster with 3 master nodes and 3 worker nodes. We are using MicroCeph for persistence, but periodically, certain pods on worker nodes are unable to be deleted or created due to an authorization error related to the Calico plugin.

Expected Behavior
Pods should be created and deleted on worker nodes at any time without encountering Calico-related authorization errors.
Current Behavior
Periodically, pods running on worker nodes cannot be evicted or scheduled due to the Calico authorization issue.
Possible Solution
The only temporary solution I've found is to delete the Calico pods associated with the worker nodes, which resolves the issue temporarily.
Steps to Reproduce (for bugs)
I'm not sure how to consistently reproduce the bug.
Context
Here are the solutions I have tried so far:
I upgraded Calico from version 3.24.5 to 3.27.4 and updated the cluster role binding using this manifest https://github.com/ClaudZen/calico-problem/blob/main/cni.yaml, but the error still occurs periodically.
I also noticed that the issue affects the /etc/nci/net.d/calico-kubeconfig file, which stops updating. As a result, the token becomes outdated, causing the problem. When I restart the Calico pod on the worker node, the file gets updated with a new token.

This is the microk8s inspect report for one affected worker node:
inspection-report-20240930_202905.tar.gz
These are my resources:

ServiceAccount
ClusterRoleBinding
ClusterRole

Your Environment

Calico version: 3.27.4
Orchestrator version (e.g. Kubernetes, Mesos, rkt): MicroK8s 1.29.9
Operating System and version: Ubuntu 22.04.4 LTS (Jammy Jellyfish)
MicroCeph is deployed on the 3 master nodes
Master nodes specs: 4 cores, 60 GB disk, 100 GB disk, 8 GB RAM
Worker nodes specs: 4 cores, 60 GB disk, 16 GB RAM

Request for Help
I would appreciate any guidance or help in understanding why this issue with Calico token authorization occurs periodically and how it might be permanently resolved. Specifically, I am interested in learning:

How to ensure the /etc/cni/net.d/calico-kubeconfig file remains up-to-date without needing to restart the Calico pods.
If there are any best practices for managing token updates with Calico to avoid outdated tokens.
Any known issues related to this behavior in Calico or MicroK8s, and if there are fixes or configurations I should be aware of.

Thank you in advance for any help or insights you can provide.

I'm also pretty consistently running into this issue as well.

For anyone hitting this, there are a number of potentially related issues (or at least issues with similar symptoms) to look at (e.g.,  https://github.com/projectcalico/calico/issues/9271)
This comment summarizes some of the things to check: https://github.com/projectcalico/calico/issues/8368#issuecomment-2120873448

@ClaudZen based on your description, I think this might be something different than the resolution for the linked issue though - you don't seem to have any RBAC resources in the process of being deleted, and you are not installing using the tigera/operator.
In general, I'd highly recommend using the tigera/operator to manage Calico - it should provide a better experience and is where the majority of our testing and development is focused.
Some things to check:

Is Calico getting throttled by the apiserver? (https://github.com/projectcalico/calico/issues/7694)
Is your cluster configured to use token projection for service account tokens? (https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection)
Have you made any changes in your calico.yaml from the upstream manifests?
Are there any error / warning logs from the calico-node pod on the affected node?

@ClaudZen @nicjohnson145 any additional info on your end?

Feel free to reopen if you managed to narrow the issue down and/or have additional information like tcpdumps, logs, iptables dumps etc.


Add Owner to GraphRbac

Fix https://github.com/Azure/azure-sdk-for-python/issues/1359

Codecov Report

Merging #1599 into master will increase coverage by 0.03%.
The diff coverage is 95.78%.

@@            Coverage Diff             @@
##           master    #1599      +/-   ##
==========================================
+ Coverage   54.69%   54.72%   +0.03%
==========================================
  Files        3680     3683       +3
  Lines       90960    91040      +80
==========================================
+ Hits        49750    49826      +76
- Misses      41210    41214       +4

Impacted Files
Coverage Δ

azure-graphrbac/azure/graphrbac/models/__init__.py
100% <100%> (ø)
:arrow_up:

...phrbac/azure/graphrbac/models/service_principal.py
100% <100%> (ø)
:arrow_up:

...re-graphrbac/azure/graphrbac/models/application.py
100% <100%> (ø)
:arrow_up:

...aphrbac/azure/graphrbac/models/directory_object.py
100% <100%> (ø)

...c/azure/graphrbac/models/directory_object_paged.py
100% <100%> (ø)

...aphrbac/models/application_add_owner_parameters.py
100% <100%> (ø)

azure-graphrbac/azure/graphrbac/models/ad_group.py
100% <100%> (ø)
:arrow_up:

...phrbac/operations/service_principals_operations.py
37.36% <90.47%> (+6.92%)
:arrow_up:

...re/graphrbac/operations/applications_operations.py
39.9% <94.59%> (+11.49%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bcc052b...1556c93. Read the comment docs.


Meetup Suggestion: Example Bitcoin Meetup

Thanks for making a suggestion for a new meetup.
Please note: Only suggest bitcoin-only meetups.
Meetups which promote any coin or token other than Bitcoin are not suitable for listing.
Altcoin's are only mentioned in the context of warnings or lessons learnt for bitcoin.
Required:

Name of Meetup:  Bitcoin for India
Location Of Meetup: bonobo bandra Mumbai
At least one of the following:

Meetup Page (or similar):
Telegram Group (or similar):
Website: https://lu.ma/History_Of_Money

Optional

Name of Organiser(s) & Twitter Handle: @raahulchoudhary1 @bitcoin4india
Links showing public support: >>>  example
Tweet your commitment

As the organiser of [>>>XXX<<<] Meetup I can confirm that the meetup is bitcoin-only
-The meetup is bitcoin focused.
-'Altcoins' are scams and are not promoted in talks/presentations at our meetups.
#bitcoinonlymeetups @bitcoinonly_

Do you have any tweets about the meetup?

Its over. Next one will share soon.


docker-make throws erroneous WARNINGS in a repository that has no git tags applied

Attempting to run docker-make (latest version on dockerhub) emits errors if the repository being run against has never had any git tags applied to it. Even if the .docker-make.yaml file does not specify use of any tags.
docker-make also seems to be attempting to convert my last commit message to a tag erroneously. Perhaps as a result of this issue.
git describe --tags seems to only be called from:
https://github.com/CtripCloud/docker-make/blob/d392161262c8d8d9e97b9e2ac9013f19e4f851a5/dmake/template_args.py#L90
For info on why git returns this error please see:
https://stackoverflow.com/a/5371322/3902629
$ git describe --tags
fatal: No names found, cannot describe anything.

$ make build
docker run --rm -w /usr/src/app -v ~/.docker:/root/.docker -v /var/run/docker.sock:/var/run/docker.sock -v "/Users/glenn/src/chainpoint/chainpoint-node-src":/usr/src/app jizhilong/docker-make:latest docker-make --no-push
WARNING dmake.template_args(101) 2017-10-08 19:27:59,960 3509d79 Upgrade request and request-promise-native is not a valid docker tag name,will be automatically corrected to 3509d79_Upgrade_request_and_request-promise-native
INFO dmake.template_args(59) 2017-10-08 19:28:00,032 failed to run git describe --tags: Command 'git describe --tags' returned non-zero exit status 128
WARNING dmake.template_args(101) 2017-10-08 19:28:00,080 3509d79 Upgrade request and request-promise-native is not a valid docker tag name,will be automatically corrected to 3509d79_Upgrade_request_and_request-promise-native
INFO dmake.template_args(59) 2017-10-08 19:28:00,153 failed to run git describe --tags: Command 'git describe --tags' returned non-zero exit status 128
INFO dmake.build(147) 2017-10-08 19:28:00,156 chainpoint-node: building
INFO dmake.build(147) 2017-10-08 19:28:02,295 chainpoint-node: attaching labels
INFO dmake.build(147) 2017-10-08 19:28:02,421 chainpoint-node: label added: org.chainpoint.git.commitid="3509d79cebab160eebc97b0ea600876cee1017e8"
INFO dmake.build(147) 2017-10-08 19:28:02,422 chainpoint-node: build succeed: 4ab850a176b0
INFO dmake.build(147) 2017-10-08 19:28:02,460 chainpoint-node: tag added: quay.io/chainpoint/chainpoint-node:3509d79cebab160eebc97b0ea600876cee1017e8
INFO dmake.build(147) 2017-10-08 19:28:02,487 chainpoint-node: tag added: quay.io/chainpoint/chainpoint-node:latest

.docker-make.yml:
builds:
  chainpoint-node:
    context: .
    dockerfile: Dockerfile
    pushes:
      - 'always=quay.io/chainpoint/chainpoint-node:{fcommitid}'
      - 'on_branch:master=quay.io/chainpoint/chainpoint-node:latest'
    labels:
      - 'org.chainpoint.git.commitid={fcommitid}'
    dockerignore:
      - .git

@grempe thanks for reporting this issue.
for the warning on failed git describe --tags invocations, I believe it should be fixed in #9 .
As you mentioned, the related commands should never get code if the template arg is not referenced by docker-make.yml,  and I think a more appropriate way is to evaluate the value of tag template arguments lazily.

I don't think this is resolved. The merge you reference is from 7 months ago. I am seeing this issue continuing using Docker image jizhilong/docker-make:latest docker-make --no-push as shown in my full output above.


Added Academy Software Foundation Forum(ASWF) Open Source Forum

Hello @Sergius-Nyah thanks for your efforts. Unfortunately, you made a PR to the 2023 list. Also, I have added the conference to the 2024 list. Thank you so much for your contributions.

Great!
Thank you @mesrenyamedogbe


Should be able to delete DS when sfc is not binded to a security group

Description
In neutron sfc, when sfc is not binded  to security group, any Deployment spec under virtual systems connected to the given sfc , can be deleted
Expected Behavior
Should be able to delete DS under a virtual system connected a sfc, if any SG is binding to the give sfc.
Actual Behavior
Deletion of DS fails with an exception saying cannot delete DS referencing to a sfc, even though the sfc is not binded to any SG
Steps to Reproduce

Create SFC chain with atleast one virtual system
Configure a DS  under the virtual system
now delete the DS.

Additional Information
This is a requirement change proposed by Arvind , on DS deletion with SFC plugin
Environment

OSC Version/Build:
OSC build -118
Cloud Provider Info:
Plugin Info:
Other:

Status

[ x] Reproduced
[ ] In Progress
[ ] Validated     =>    Verified in Version/Build:

DE5354

Verified with Build Version: 1.0.0-SNAPSHOT (Build:142-g0fb43fe, 2017-10-26T07:20:58Z)
Able to delete the DS when SG is not sfc-binded to the DA
securityBroker-DS-deleted-when-SFC-SG-unbinded.log


Unable to modify fileName and lineNumber in errCreate

I'm not sure if this is by design, but I've found that this doesn't work:
Duktape.errCreate = function(e) { e.fileName = "the pig"; e.lineNumber = 812; return e; };

Similarly, using duk_put_prop() to modify those properties (my actual errCreate is implemented in C) doesn't work either.  However, this does work:
	duk_push_string(ctx, "fileName"); duk_push_string(ctx, "the pig");
	duk_def_prop(ctx, 0, DUK_DEFPROP_HAVE_VALUE
		| DUK_DEFPROP_HAVE_WRITABLE | DUK_DEFPROP_WRITABLE
		| DUK_DEFPROP_HAVE_CONFIGURABLE | DUK_DEFPROP_CONFIGURABLE
		| DUK_DEFPROP_HAVE_ENUMERABLE | 0);
	duk_push_string(ctx, "lineNumber"); duk_push_int(ctx, 812);
	duk_def_prop(ctx, 0, DUK_DEFPROP_HAVE_VALUE
		| DUK_DEFPROP_HAVE_WRITABLE | DUK_DEFPROP_WRITABLE
		| DUK_DEFPROP_HAVE_CONFIGURABLE | DUK_DEFPROP_CONFIGURABLE
		| DUK_DEFPROP_HAVE_ENUMERABLE | 0);

The fact that the latter snippet works means the properties are configurable, but not writable, by default?  Seems odd, and makes error augmentation more difficult.

Error .fileName and .lineNumber are not "own properties" of the error but rather automatically created by an inherited getter. The getter return value is based on the internal _Tracedata property. This arrangement minimizes "own property" counts for errors:
((o) Duktape 1.3.99 (v1.3.0-88-gbdbe2d1-dirty)
duk> err = new Error('aiee');
= Error: aiee
duk> print(Duktape.enc('jx', Object.getOwnPropertyDescriptor(err, 'fileName')));
undefined
= undefined
duk> print(Duktape.enc('jx', Object.getOwnPropertyDescriptor(Error.prototype, 'fileName')));
{get:{_func:true},set:{_func:true},enumerable:false,configurable:true}
= undefined

As a side effect, attempt to overwrite either property will be captured by the inherited setter. The current setter is a silent nop.
The inherited setter/getter has been left configurable so that it is possible to create an "own property" of the same name using Object.defineProperty(); if the setter/getter were non-configurable, that would also be rejected.
So, the current behavior is by design but it's not necessarily the nicest one.
One improvement might be to make the default setter create the "own property" automatically so that assignment would seem to work normally.

Here's a "polyfill" to emulate the setter change I suggested:
Object.defineProperty(Error.prototype, 'fileName', {
    set: function (v) {
        Object.defineProperty(this, 'fileName', {
            value: v,
            writable: true,
            enumerable: false,
            configurable: true
        });
    }
});

With this in place you'll be able to write the fileName:
duk> err = new Error('aiee'); print(err.fileName);
input
= undefined
duk> err.fileName = 'dummy';
= dummy
duk> err.fileName
= dummy
duk> Duktape.enc('jx', Object.getOwnPropertyDescriptor(err, 'fileName'));
= {value:"dummy",writable:true,enumerable:false,configurable:true}

The same approach for .lineNumber works of course, perhaps with number coercion in the setter.

Thanks.  The current behavior is not a big deal (defineProperty works after all), I just wanted to make sure it was by design and not a bug like with Function#name a while back.

Ok, good to hear. That setter change would be quite easy though. It's worth a Wiki howto at least because it's certainly a bit unintuitive.

The setter would indeed be convenient, but I didn't know if you actually wanted to add it or not (for footprint reasons).

#390 has the diff needed to make the change -- I'm not sure it's a good idea but it's up for discussion :)


PDFs with text generated on Windows cannot be opened

Exporting any canvas containing any label to PDF in Windows causes the PDF to be invalid.
As a result, most of PDF tools cannot open the file. Adobe Reader shows error 135.
Output from an online validation tool:

The "endobj" keyword is missing.
The key FirstChar is required but missing.
The key LastChar is required but missing.
The key Widths is required but missing.
The key FontDescriptor is required but missing.
The document does not conform to the requested standard.
The file format (header, trailer, objects, xref, streams) is corrupted.
The document doesn't conform to the PDF reference (missing required entries, wrong value types, etc.).
The document does not conform to the PDF 1.5 standard.

The issue is not present on Linux.
Sample code:
c := RSCanvas new.

c add: (RSLabel new text: 'A'; yourself).

c exportToPDF

Tested with latest release and latest master of both Roassal and RoassalExporters, with Pharo 11 and 13 on Windows 11 (and on Debian 12 where it works).

Thanks Jan. This is strange because roassal uses the cairo back-end for this. I tried in Mac and it works.
3905409273136084.pdf

Thanks Jan. This is strange because roassal uses the cairo back-end for this. I tried in Mac and it works.<PHONE_NUMBER>136084.pdf

This is actually not the only problem I am having on specific platforms with Roassal/Cairo. On Linux, italic and bold emphasis for RSLabel does not work: https://github.com/pharo-graphics/Roassal/issues/71

Hello. It is possible to try a more recent version of cairo. A procedure to do it is described for Alexandire in this document.

Hello. It is possible to try a more recent version of cairo. A procedure to do it is described for Alexandire in this document.

Thank you, this helped a lot.
On Ubuntu 24, it updates to:
Cairo 1.18.0
FreeType 2.13.2
HarfBuzz 8.3.0
On Windows, I used libs from Inkscape 1.4rc1:
Cairo 1.18.0,
FreeType 2.13.2,
Harfbuzz 9.0.0
and both issues got fixed by it, so it is both fault of the specific version of Cairo/FreeType/whatever bundled with these libraries used by Pharo.
Well, few Roassal tests fail now, but just 3 on Ubuntu and 2 on Windows.

Oh, I see Harfbuzz has now 10.0.1. The expert in updating the vm's libs is @tesonep, it's not easy task at all!

Oh, I see Harfbuzz has now 10.0.1. The expert in updating the vm's libs is @tesonep, it's not easy task at all!

Sure, I can image it can cause more problems than it solves. For example, in version 1.18.0 do not work italics on Mac (in our 1.17.4 it is on Linux) and in 1.18.2 does not work PDF export on all platforms... (https://gitlab.freedesktop.org/cairo/cairo/-/issues/870)


Allow tz-aware inputs in Holiday.dates

closes #9824
Previously, passing tz-aware inputs to Holiday.dates would always result in an error because the the input start_date was converted in a way that destroyed timezone information.  This PR makes that conversion correctly preserve tz info, and converts several of the existing tests to run with both tz-aware and tz-naive inputs.
Noticed while working on a new trading calendar implementation here: https://github.com/quantopian/zipline/pull/556.

your tests don't check for a holiday with a timezone. wasn't this the use case?

@jreback the specific issue solved here is that calling holiday.dates(start, end) with tz-aware start and end raises an error because it ultimately constructs a DatetimeIndex with a tz-naive start and the supplied end.  The fix here just propagates the timezone of the supplied start so that the call succeeds if both inputs are tz-aware and in the same timezone.  That's tested at https://github.com/pydata/pandas/pull/9824/files#diff-96b913a0de65ff4f70fc5bde0543e9a8R62 by running the same checks that were performed previously, but with dates that are localized to UTC.

@ssanderson ok, I see, then ok!
pls squash and good to go

@jreback squashed into one commit and rebased with master.  I assume that's what you meant?

@ssanderson yep
thanks for the PR!

@jreback great!  https://github.com/pydata/pandas/issues/9825 can be closed (I mistyped in my issue description).

fixed thanks!