1. 22 Sep, 2022 2 commits
  2. 21 Sep, 2022 2 commits
  3. 20 Sep, 2022 1 commit
  4. 18 Sep, 2022 13 commits
  5. 17 Sep, 2022 9 commits
    • update env remove logic (#6195) · 2def3571
      Resolves: #6018 
      
      1. Added a check so that if `python` argument is a file (then it should
      be a python path) - extract it's venv name and raise `IncorrectEnvError`
      if it doesn't belong to this project
          **Before**
          ```
      └❯ poetry env remove
      ~/.cache/pypoetry/virtualenvs/different-project-OKfJHH_5-py3.10/bin/python
          /bin/sh: 1: different-project-OKfJHH_5-py3.10: not found
      
      Deleted virtualenv: ~/.cache/pypoetry/virtualenvs/poetry-4pWfmigs-py3.10
          ```
          Removes current project's env, which is wrong.
          **After**
          ```
      └❯ poetry env remove
      ~/.cache/pypoetry/virtualenvs/different-project-OKfJHH_5-py3.10/bin/python
      
      Env different-project-OKfJHH_5-py3.10 doesn't belong to this project.
          ```
      2. Added the exact same check as before ^, but for cases where env name
      is passed.
          **Before**
          ```
          └❯ poetry env remove different-project-OKfJHH_5-py3.10      
           /bin/sh: 1: different-project-OKfJHH_5-py3.10: not found
      
      Command different-project-OKfJHH_5-py3.10 -c "import sys;
      print('.'.join([str(s) for s in sys.version_info[:3]]))" errored with
      the following return code 127, and output:
          ```
      Errors while trying to exec env name as an interpreter, error is not
      clear.
          **After**
          ```
      └❯ poetry env remove different-project-OKfJHH_5-py3.10
      
      Env different-project-OKfJHH_5-py3.10 doesn't belong to this project.
          ```
      3. Added a couple of tests for **new** and for **old** scenarios which
      weren't tested.
      4. Added `venv_name` fixture for `tests/utils` directory to use in
      `test_env`. Also replaced some of `"simple-project"` hardcoded value to
      use `poetry.package.name`
      
      It's up to maintainers to choose what they want for this project - I'm
      happy either way if we at least fix the bug. I can remove/change any of
      the stuff I added on top of the fix. But yeah I just decided that if we
      fix the bug, we might also make some improvements/changes in this area
      of code. Any thoughts on this are welcome, thanks!
      Alexey committed
    • Avoid the deprecated JSON API (#6081) · b61a4ddb
      Resolves #6076 
      
      I've taken the JSON version of the simple API and converted it into a
      `LinkSource` so that the package-finding logic in the `PyPiRepository`
      is very similar to - but annoyingly not quite the same as! - the
      `LegacyRepository`.
      
      I've also taken the opportunity to refactor the `LegacyRepository` ever
      so slightly to emphasise that similarity. I think I've probably fixed a
      small bug re caching and pre-releases: previously the processing for
      ignored pre-releases was skipped when reading from the cache.
      
      I believe this change will tend to be a modest performance hit. Eg
      consider a package like `cryptography`, for which there are maybe a
      couple of dozen downloads available at each release: to get the
      available versions we now have to iterate over each of those files and
      parse their names, rather than simply reading the answer.
      
      However if the API that poetry currently uses is truly deprecated I see
      little choice but to suck that up - or risk being in an awkward spot
      when it is turned off. cf #5970, but worse.
      
      Most of the changes are in the test fixtures:
      - unversioned fixtures were generated from the existing fixtures: I
      didn't want to download fresh data and start getting different answers
      than the tests were expecting
      - new versioned fixtures were downloaded fresh
      David Hotham committed
    • ci: use flake8-pie (#6164) · c1aff5c9
      Relates-to: #4776 
      
      Adding the hook leads to four new warnings for the repo.
      -
      [PIE803](https://github.com/sbdchd/flake8-pie#pie803-prefer-logging-interpolation):
      prefer-logging-interpolation
      This check produces false positives (`debug()` calls are always flagged
      as if they belong to a logger). PR ignores such instances and fixes the
      rest.
      -
      [PIE786](https://github.com/sbdchd/flake8-pie#pie786-precise-exception-handlers):
      precise-exception-handlers
      PR ignores instances where the intention is indeed to catch any
      exceptions and fixes the rest.
      -
      [PIE798](https://github.com/sbdchd/flake8-pie#pie798-no-unnecessary-class):
      no-unnecessary-class
      All instances are ignored via an additional entry in flake8 config.
      Alp Arıbal committed
    • refactor(uploader): don't use normalize_version() or escape_version() (#6476) · a14a93d9
      When you already have a `Version` in hand,
      `normalize_version(version.text)` is a very roundabout way of calling
      `version.to_string()`: it re-parses the version text to give you the
      same `Version` you already had and then calls `to_string()` on that.
      
      https://github.com/python-poetry/poetry-core/blob/37cee90a5dd4c7ee2c5ee836216ba813242b3ade/src/poetry/core/utils/helpers.py#L27-L28
      
      Then calling `escape_version()` on such a version is actually
      counter-productive, per #6466.
      
      Similar changes can and should be made over in poetry-core, but it
      should be safe to merge this before that is done.
      David Hotham committed
    • solver: make results of `poetry update` more deterministic and similar to results of `poetry lock` · 4914c265
      When running `poetry lock`, dependencies with less candidates are chosen first.
      Prior to this change when running `poetry update`, all whitelisted dependencies (aka `use_latest`) got the same priority which results in a more or less random resolution order.
      Randy Döring committed
    • chore: post 1.2.1 cleanup · ebee342c
      Randy Döring committed
  6. 16 Sep, 2022 2 commits
  7. 15 Sep, 2022 2 commits
  8. 14 Sep, 2022 2 commits
  9. 13 Sep, 2022 1 commit
  10. 12 Sep, 2022 2 commits
  11. 11 Sep, 2022 3 commits
  12. 10 Sep, 2022 1 commit