Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

pip freeze does not list repo url #609

Closed
DataGreed opened this issue Jul 24, 2012 · 40 comments · Fixed by #7612
Closed

pip freeze does not list repo url #609

DataGreed opened this issue Jul 24, 2012 · 40 comments · Fixed by #7612
Labels
C: freeze C: PEP 517 impact C: vcs PEP implementation state: blocked type: feature request

Comments

@DataGreed
Copy link

@DataGreed DataGreed commented Jul 24, 2012

Here's the detailed problem: http://stackoverflow.com/questions/11560056/pip-freeze-does-not-show-repository-paths-for-requirements-file

@qwcode
Copy link
Contributor

@qwcode qwcode commented Jul 28, 2012

pip's ability to discern where the install came from is limited after the fact using pip freeze.
pip internally relies upon setuptools to find all the installed distributions.
pip then checks to see if any of them are "editable"/-e vcs installations.
if editable, then it will print out the vcs url.
if not editable, then just the name=version spec.

btw, since you asked about "-e" in the stack link, "-e" or "editable" is an enhancement of what setuptools called a "develop" install. this is an "installation" that does not occur via copying packages into site-packages.
but rather a link of sorts is made in site-packages back to the source location of the project.
that way you can "develop" or "edit" the project live while it's installed.
for "-e" vcs installs, pip uses a "src" subdirectory of the virtualenv or sys.prefix to clone the project.
if you install from a vcs url w/o "-e", pip builds a distribution locally and installs from that, and at that point pip freeze (i.e. setuptools) doesn't know it came from vcs.

@xavfernandez
Copy link
Member

@xavfernandez xavfernandez commented Oct 15, 2016

A typical example is given in #4005.

$ pip install git+https://github.com/chadmiller/textbot_metapriv.git#egg=textbot_metapriv   # a private package that will never be in PyPI
$ pip freeze |grep bot
textbot-metapriv==1.0

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Sep 28, 2017

@xavfernandez is this still an issue?

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Oct 2, 2017

is this still an issue?

Yes.

@pradyunsg pradyunsg added state: awaiting PR type: enhancement labels Oct 2, 2017
@cjerdonek cjerdonek added the C: vcs label Aug 18, 2018
@sbidoul
Copy link
Member

@sbidoul sbidoul commented Mar 30, 2019

What's the problem this feature will solve?

Abstract: this issue is becoming more acute now that pep517 is a thing and it does not support editable installs.

When installing vcs dependencies without --editable, the exact installed version is lost when subsequently doing a pip freeze. When installing with --editable, it is preserved.

Preserving the installed vcs reference is actually my main (if not only) use case for using --editable.

My problem today is that pep517 does not support --editable, so if I want to pip install from vcs a pep517 project which has no setup.py, I loose the ability to do a reliable pip freeze.

Here is an example installing a pep517 project in a virtualenv (flit):

$ mktmpenv -p python3
$ pip install git+https://github.com/takluyver/flit.git
$ pip freeze
certifi==2019.3.9
chardet==3.0.4
docutils==0.14
flit==1.3
idna==2.8
pytoml==0.1.20
requests==2.21.0
urllib3==1.24.1

So with this method, I loose the information about the exact flit commit installed, and pip freeze does not give me something reproducible.

If I try with -e, it fails because pip install -e assumes setuptools is present:

$ mktmpenv -p python3
$ pip install -e git+https://github.com/takluyver/flit.git#egg=flit
[...]
Installing collected packages: certifi, chardet, urllib3, idna, requests, pytoml, docutils, flit
  Running setup.py develop for flit
    Complete output from command /home/sbi/.virtualenvs/tempenv-04f816243221f/bin/python3 -c "import setuptools, tokenize;__file__='/home/sbi/.virtualenvs/tempenv-04f816243221f/src/flit/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    ModuleNotFoundError: No module named 'setuptools'

Describe the solution you'd like

I understand adding editable support to pep517 is a hard problem. Perhaps it is not needed for this use case, and a simpler approach would be to have pip preserve the installed vcs reference somewhere to restitute it in pip freeze?

I'm willing attempt a PR, but I'm not sure where pip could store this information, assuming such a place exists at all today? Could someone give me some guidance as to where to start?

@cjerdonek cjerdonek added state: needs discussion type: feature request and removed state: awaiting PR type: enhancement labels Mar 30, 2019
@cjerdonek
Copy link
Member

@cjerdonek cjerdonek commented Mar 31, 2019

Could someone give me some guidance as to where to start?

I don't think what you're asking has a simple or clear solution, so I'd suggest beginning by gathering / brainstorming ideas. Also, is this a feature that you're thinking would be limited to things installed with pip?

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Mar 31, 2019

@cjerdonek Thanks for jumping in. Here are some thoughts.

So we'd need some sort of metadata in dist-info. Perhaps a VCSORIGIN field?

  • it would be specified to be a frozen VCS reference (a git commit, not branch or tag)
  • it would supersede the version for the purpose of pip freeze
  • it would supersede the version as wheel cache entry key

Could work, but I dot not feel very comfortable with it and when thinking about this I always come back to editable installs.

I played a bit with poetry and flit.

In presence of a git dependency, poetry always does an "editable" install, in the sense it creates a .egg-link, so pip freeze works.

Flit, like pip install without -e, does nothing special and loses the VCS origin after installation so pip freeze does not work.

OTOH, flit has an interesting 'install --symlink' which generates a regular .dist-info, but does not copy the source code and symlinks it instead (or plays with .pth files in a variant that supports platforms without symlinks). pip freeze does not work in this case either because it exclusively relies on the presence of .egg-link to find the source location.

I like what flit does here very much, as it uses dist-info metadata and is very flexible

So a better approach could be going all the way to implement "editable" installs in pep 517? I could not find the discussion that led to its temporary exclusion from pep 517. From the use cases I can imagine it could be relatively simple along these lines:

  • backend provides prepare_metadata_for_install_editable() and install_editable()
  • backend has the choice to install with the .egg-link method, or .dist-info + symlink, or .dist-info + any other mechanism it wants (.pth, etc)
  • when doing an editable install, frontends (or should it be backend?) add a LOCATION metadata to record the source path of the install
  • pip (or pkg_resources?) uses the new LOCATION metadata to detect editable installs so pip freeze can continue working normally
  • when editable installs create a .dist-info, pip uninstall would work normally (no need to special case, since the RECORD would simply contain the symlinks to be removed)

If we can go with the editable install approach, we could then close this issue as not supported and direct people who need it to use --editable.

Perhaps I'm opening too big a can of worms? Yet I think editable installs must become part of pep 517 sooner than later, and this could be a good motivation to move it forward.

Is it the right place to brainstorm this? Should we involve other people here or open the discussion somewhere else?

@cjerdonek
Copy link
Member

@cjerdonek cjerdonek commented Mar 31, 2019

Should we involve other people here or open the discussion somewhere else?

If you wanted a wider discussion, the best place is probably to start a new topic under the "Packaging" category of the Python Discourse instance: https://discuss.python.org/c/packaging

I'm not sure how much traction you'll get though because PEP 517 was complex and highly contentious and drawn out (one of the reasons for removing editable), and there was an update even as recently as a month or so ago. So I'm guessing the participants will need a breather before picking up a new, hard topic like this that has long-term implications.

But it could help to get people thinking and get some initial thoughts.

@sbidoul
Copy link
Member

@sbidoul sbidoul commented May 12, 2019

The discussion on the spec which is a prerequisite to implement this is at https://discuss.python.org/t/draft-pep-recording-the-origin-of-distributions-installed-from-direct-url-references/1535

@DataGreed
Copy link
Author

@DataGreed DataGreed commented Jun 27, 2019

Wow, never expected that my feature request from seven years ago would still be discussed and even had a spec written on it.

You have my respect.

@chrahunt
Copy link
Member

@chrahunt chrahunt commented Oct 6, 2019

Related PEP: python/peps#1145

@chrahunt chrahunt added PEP implementation state: blocked and removed state: needs discussion labels Oct 6, 2019
@pfmoore
Copy link
Member

@pfmoore pfmoore commented Nov 15, 2019

Don't worry about BDFL-Delegate, as I have that role for all packaging interop PEPs.

A sponsor is a requirement for the PEP process, so I think you do need one. Also, the fact that you have all these questions is precisely what having a sponsor should address. It's difficult to argue that you don't need one because @cjerdonek co-authored, while still pointing out that he's currently not available and hence you need all of these questions answered ;-)

Honestly, I think you may be better just waiting for @cjerdonek to be available to assist - I'm not clear why this PEP is so urgent that it couldn't wait for that.

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Nov 15, 2019

I'm not clear why this PEP is so urgent that it couldn't wait for that.

In good open source tradition, I have an itch that I can scratch by implementing this issue (which was tagged awaiting PR back then).

In the grand scheme of things, nothing is urgent of course. This issue is 7 years old. I proposed to work on it 7 months ago, did all the PEP writing and editorial work with Chris (4 months), then waited 3 more months after opening the PEP PR, before concluding that Chris was not available and kindly asking for an alternative to get it moving.

I'm not complaining nor anything, yet I must say I feel more and more like Asterix in his 12 tasks, in the part when he has to navigate a kafkaian administration ;-)

@pfmoore
Copy link
Member

@pfmoore pfmoore commented Nov 15, 2019

I sympathise. Maybe the best approach would be to ask on the original thread for this PEP for someone who can act as a sponsor. That's the most likely place to find someone who is a core dev, who is also interested in the proposal.

@bmartinn
Copy link

@bmartinn bmartinn commented Dec 19, 2019

Hey @sbidoul, I'm not sure if it helps expedite the process, but you have my vote as well :)

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Jan 7, 2020

@bmartinn thanks for the support.

There were a few comments on PEP 610 since it's up for review (thanks @uranusjr and @chrahunt), none of which raising blocking issue on the concept. However the PEP has not raised interest from python core devs, so that path seems to be closed for now.

That said I'm still very much motivated to implement this pip freeze improvement.

@pypa/pip-committers, would you see an objection if I make a PR that solves this issue, by implementing PEP 610, except it would name the file pip_direct_url.json and make it clear the file is reserved for pip private use? I don't think there is anything that prevents tools to add their own files into .dist-info directories.

This could serve as a real world implementation for the PEP, to discover and weed out any issue in it.

We would not document the file format and we'd make it clear that the file is not intended to be interoperable, and that if other tools want to use it people need to go and review PEP 610. This way we are not growing the pip public surface area, we are just making pip freeze work the way it should in more cases.

If and when the PEP get approved, it will be easy to introduce a transition path.

@bmartinn
Copy link

@bmartinn bmartinn commented Jan 13, 2020

@sbidoul for what it's worth, I think that's a good compromise. It will definitely expand the transparency of the installed packages on the system, with not a lot strings attached (in terms of committing to a strict standard).

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Jan 15, 2020

@bmartinn the PEP got a new sponsor, so thing are moving again. I'm currently writing a new version of the PEP that integrates all the review comments.

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Jan 25, 2020

A proposed implementation is in #7612. People interested in testing this can do it by installing pip from that branch: python -m pip install -U git+https://github.com/pypa/pip@refs/pull/7612/head.

@bmartinn
Copy link

@bmartinn bmartinn commented Jan 26, 2020

Thanks @sbidoul ! I'll check the PR

@josephcappadona
Copy link

@josephcappadona josephcappadona commented Feb 12, 2020

A proposed implementation is in #7612. People interested in testing this can do it by installing pip from that branch: python -m pip install -U git+https://github.com/pypa/pip@refs/pull/7612/head.

Just wanted to chime in saying that this worked for me!

@thomasgilgenast
Copy link

@thomasgilgenast thomasgilgenast commented Feb 16, 2020

A proposed implementation is in #7612. People interested in testing this can do it by installing pip from that branch: python -m pip install -U git+https://github.com/pypa/pip@refs/pull/7612/head.

Also chiming in to say I've used this PR to create "nested" dependencies (i.e., packageA depends on packageB depends on packageC, etc.) by using PEP 440 direct references to git repositories in setup.py's setup_requires in such a way that virtual environments survive a "round trip" of pip install packageA -> pip freeze > requirements.txt -> pip install -r requirements.txt without any manual editing of the requirements.txt file. I don't think this was possible to do with pip+setup.py at all before this PR, because the repo URL was only written to requirements.txt if the package was installed in editable mode, and I don't think there's a way to indicate that a dependency should be installed in editable mode in setup.py. With this PR, everything "just works" as a naive user might expect.

In short, this PR (and the Herculean effort being put in to create PEP 610 and address this issue) helps users like me who are still running into the pre-PEP-517/518 variant of this issue too.

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Apr 16, 2020

@pradyunsg is this feature worth calling out in the release notes?

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Apr 16, 2020

Wouldn't the entry for #609 cover this?

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Apr 25, 2020

We have now (per #7951) published a beta release of pip, pip 20.1b1. This release includes #7612, which implemented a solution for this issue.

I hope participants in this issue will help us by testing the beta and checking for new bugs. We'd like to identify and iron out any potential issues before the main 20.1 release on Tuesday.

I also welcome positive feedback along the lines of "yay, it works better now!" as well, since the issue tracker is usually full of "issues". :)

@bmartinn
Copy link

@bmartinn bmartinn commented Apr 25, 2020

@pradyunsg It works!!! It's so awesome!

Minor caveat though :)

If you do

sudo pip install git+https://github.com/...

Then when you run pip freeze (notice not sudo)
You get the following exception:

ERROR: Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 188, in _main
    status = self.run(options, args)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/commands/freeze.py", line 98, in run
    for line in freeze(**freeze_kwargs):
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/operations/freeze.py", line 68, in freeze
    req = FrozenRequirement.from_dist(dist)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/operations/freeze.py", line 256, in from_dist
    direct_url = dist_get_direct_url(dist)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/utils/direct_url_helpers.py", line 118, in dist_get_direct_url
    return DirectUrl.from_json(dist.get_metadata(DIRECT_URL_METADATA_NAME))
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/pkg_resources/__init__.py", line 1420, in get_metadata
    value = self._get(path)
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/pkg_resources/__init__.py", line 1616, in _get
    with open(path, 'rb') as stream:
PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.6/site-packages/trains-0.14.1.dist-info/direct_url.json'

As you can see the direct_url.json file is missing the r flag for group / others , which raises the exception.

-rw------- 1 root root 135 Apr 25 23:22 /usr/local/lib/python3.6/site-packages/trains-0.14.1.dist-info/direct_url.json

I tested running chmod 644 on this file, and after that pip freeze works like a charm.

Other than this minor issue, great job guys! 👍

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Apr 25, 2020

@bmartinn That's expected. I think that's a permissions situation with your system. Any files created by a sudo'ed command would be owned by root, and it might be the case that these files aren't readable. To verify this -- check if anything in /usr/local/lib/python3.6/site-packages/trains-0.14.1.dist-info/ is readable by group/others. :)

Other than that, in general, we strongly recommend users to not use sudo pip, to avoid conflicting with the system package manager (see https://stackoverflow.com/questions/21055859/what-are-the-risks-of-running-sudo-pip/22517157#22517157).

@bmartinn
Copy link

@bmartinn bmartinn commented Apr 25, 2020

@pradyunsg I verified, the top_level.txt file next to the direct_url.json file has the correct permission...
I also opened an issue, so it doesn't get lost #8139

Other than that, in general, we strongly recommend users to not use sudo pip, to avoid conflicting with the system package manager (see https://stackoverflow.com/questions/21055859/what-are-the-risks-of-running-sudo-pip/22517157#22517157).

Definitely agree on this one, but you asked to test the new feature, so I did :)

@pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Apr 27, 2020

Ah yes, I was wrong about why this is happening. :)

Thanks for filing that separate issue @bmartinn and your report is much appreciated! ^>^

bors bot added a commit to duckinator/emanate that referenced this issue May 13, 2020
118: Update pip to 20.1 r=duckinator a=pyup-bot


This PR updates [pip](https://pypi.org/project/pip) from **20.0.2** to **20.1**.



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

Process
-------

- Document that pip 21.0 will drop support for Python 2.7.

Features
--------

- Add ``pip cache dir`` to show the cache directory. (`7350 &lt;https://github.com/pypa/pip/issues/7350&gt;`_)

Bug Fixes
---------

- Abort pip cache commands early when cache is disabled. (`8124 &lt;https://github.com/pypa/pip/issues/8124&gt;`_)
- Correctly set permissions on metadata files during wheel installation,
  to permit non-privileged users to read from system site-packages. (`8139 &lt;https://github.com/pypa/pip/issues/8139&gt;`_)
   ```
   
  
  
   ### 20.1b1
   ```
   ===================

Deprecations and Removals
-------------------------

- Remove emails from AUTHORS.txt to prevent usage for spamming, and only populate names in AUTHORS.txt at time of release (`5979 &lt;https://github.com/pypa/pip/issues/5979&gt;`_)
- Remove deprecated ``--skip-requirements-regex`` option. (`7297 &lt;https://github.com/pypa/pip/issues/7297&gt;`_)
- Building of local directories is now done in place, instead of a temporary
  location containing a copy of the directory tree. (`7555 &lt;https://github.com/pypa/pip/issues/7555&gt;`_)
- Remove unused ``tests/scripts/test_all_pip.py`` test script and the ``tests/scripts`` folder. (`7680 &lt;https://github.com/pypa/pip/issues/7680&gt;`_)

Features
--------

- pip now implements PEP 610, so ``pip freeze`` has better fidelity
  in presence of distributions installed from Direct URL requirements. (`609 &lt;https://github.com/pypa/pip/issues/609&gt;`_)
- Add ``pip cache`` command for inspecting/managing pip&#39;s wheel cache. (`6391 &lt;https://github.com/pypa/pip/issues/6391&gt;`_)
- Raise error if ``--user`` and ``--target`` are used together in ``pip install`` (`7249 &lt;https://github.com/pypa/pip/issues/7249&gt;`_)
- Significantly improve performance when ``--find-links`` points to a very large HTML page. (`7729 &lt;https://github.com/pypa/pip/issues/7729&gt;`_)
- Indicate when wheel building is skipped, due to lack of the ``wheel`` package. (`7768 &lt;https://github.com/pypa/pip/issues/7768&gt;`_)
- Change default behaviour to always cache responses from trusted-host source. (`7847 &lt;https://github.com/pypa/pip/issues/7847&gt;`_)
- An alpha version of a new resolver is available via ``--unstable-feature=resolver``. (`988 &lt;https://github.com/pypa/pip/issues/988&gt;`_)

Bug Fixes
---------

- Correctly freeze a VCS editable package when it is nested inside another VCS repository. (`3988 &lt;https://github.com/pypa/pip/issues/3988&gt;`_)
- Correctly handle ``%2F`` in URL parameters to avoid accidentally unescape them
  into ``/``. (`6446 &lt;https://github.com/pypa/pip/issues/6446&gt;`_)
- Reject VCS URLs with an empty revision. (`7402 &lt;https://github.com/pypa/pip/issues/7402&gt;`_)
- Warn when an invalid URL is passed with ``--index-url`` (`7430 &lt;https://github.com/pypa/pip/issues/7430&gt;`_)
- Use better mechanism for handling temporary files, when recording metadata
  about installed files (RECORD) and the installer (INSTALLER). (`7699 &lt;https://github.com/pypa/pip/issues/7699&gt;`_)
- Correctly detect global site-packages availability of virtual environments
  created by PyPA’s virtualenv&gt;=20.0. (`7718 &lt;https://github.com/pypa/pip/issues/7718&gt;`_)
- Remove current directory from ``sys.path`` when invoked as ``python -m pip &lt;command&gt;`` (`7731 &lt;https://github.com/pypa/pip/issues/7731&gt;`_)
- Stop failing uninstallation, when trying to remove non-existent files. (`7856 &lt;https://github.com/pypa/pip/issues/7856&gt;`_)
- Prevent an infinite recursion with ``pip wheel`` when ``$TMPDIR`` is within the source directory. (`7872 &lt;https://github.com/pypa/pip/issues/7872&gt;`_)
- Significantly speedup ``pip list --outdated`` by parallelizing index interaction. (`7962 &lt;https://github.com/pypa/pip/issues/7962&gt;`_)
- Improve Windows compatibility when detecting writability in folder. (`8013 &lt;https://github.com/pypa/pip/issues/8013&gt;`_)

Vendored Libraries
------------------

- Update semi-supported debundling script to reflect that appdirs is vendored.
- Add ResolveLib as a vendored dependency.
- Upgrade certifi to 2020.04.05.1
- Upgrade contextlib2 to 0.6.0.post1
- Upgrade distro to 1.5.0.
- Upgrade idna to 2.9.
- Upgrade msgpack to 1.0.0.
- Upgrade packaging to 20.3.
- Upgrade pep517 to 0.8.2.
- Upgrade pyparsing to 2.4.7.
- Remove pytoml as a vendored dependency.
- Upgrade requests to 2.23.0.
- Add toml as a vendored dependency.
- Upgrade urllib3 to 1.25.8.

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

- Emphasize that VCS URLs using git, git+git and git+http are insecure due to
  lack of authentication and encryption (`1983 &lt;https://github.com/pypa/pip/issues/1983&gt;`_)
- Clarify the usage of --no-binary command. (`3191 &lt;https://github.com/pypa/pip/issues/3191&gt;`_)
- Clarify the usage of freeze command in the example of Using pip in your program (`7008 &lt;https://github.com/pypa/pip/issues/7008&gt;`_)
- Add a &quot;Copyright&quot; page. (`7767 &lt;https://github.com/pypa/pip/issues/7767&gt;`_)
- Added example of defining multiple values for options which support them (`7803 &lt;https://github.com/pypa/pip/issues/7803&gt;`_)
   ```
   
  
</details>


 

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



Co-authored-by: pyup-bot <github-bot@pyup.io>
@flywire
Copy link

@flywire flywire commented Dec 24, 2020

This was installed at https://pip.pypa.io/en/stable/news/#b1-2020-04-21

#7612 (comment)

In a nutshell, before it did this:

$ pip install git+https://github.com/pypa/packaging
....
$ pip freeze
packaging==20.1.dev0
pyparsing==2.4.6
six==1.14.0
Now it does this:

$ pip install git+https://github.com/pypa/packaging
....
$ pip freeze
packaging @ git+https://github.com/pypa/packaging@d49fdc500a7c057b71851847ff8d7cc92865bcf2
pyparsing==2.4.6
six==1.14.0

It isn't reporting repo url:

E:\source\repos\Temp>pip uninstall mkdocs
Found existing installation: mkdocs 1.2.dev1
Uninstalling mkdocs-1.2.dev1:
  Would remove:
    c:\users\user\appdata\local\programs\python\python39\lib\site-packages\mkdocs-1.2.dev1-py3.9.egg-info
    c:\users\user\appdata\local\programs\python\python39\lib\site-packages\mkdocs\*
    c:\users\user\appdata\local\programs\python\python39\scripts\mkdocs-script.py
    c:\users\user\appdata\local\programs\python\python39\scripts\mkdocs.exe
Proceed (y/n)? y
  Successfully uninstalled mkdocs-1.2.dev1

E:\source\repos\Temp>pip install git+https://github.com//flywire/mkdocs@GitHub-wiki
Collecting git+https://github.com//flywire/mkdocs@GitHub-wiki
  Cloning https://github.com//flywire/mkdocs (to revision GitHub-wiki) to e:\temp\pip-req-build-svg7eyc6
Requirement already satisfied: click>=3.3 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (7.1.2)
Requirement already satisfied: Jinja2>=2.10.1 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (2.11.2)
Requirement already satisfied: livereload>=2.5.1 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (2.6.3)
Requirement already satisfied: lunr[languages]==0.5.8 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (0.5.8)
Requirement already satisfied: Markdown>=3.2.1 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (3.3.3)
Requirement already satisfied: PyYAML>=3.10 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (5.3.1)
Requirement already satisfied: tornado>=5.0 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from mkdocs==1.2.dev1) (6.1)
Requirement already satisfied: future>=0.16.0 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from lunr[languages]==0.5.8->mkdocs==1.2.dev1) (0.18.2)
Requirement already satisfied: six>=1.11.0 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from lunr[languages]==0.5.8->mkdocs==1.2.dev1) (1.15.0)
Requirement already satisfied: nltk>=3.2.5 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from lunr[languages]==0.5.8->mkdocs==1.2.dev1) (3.5)
Requirement already satisfied: MarkupSafe>=0.23 in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from Jinja2>=2.10.1->mkdocs==1.2.dev1) (1.1.1)
Requirement already satisfied: joblib in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from nltk>=3.2.5->lunr[languages]==0.5.8->mkdocs==1.2.dev1) (0.17.0)
Requirement already satisfied: regex in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from nltk>=3.2.5->lunr[languages]==0.5.8->mkdocs==1.2.dev1) (2020.11.13)
Requirement already satisfied: tqdm in c:\users\user\appdata\local\programs\python\python39\lib\site-packages (from nltk>=3.2.5->lunr[languages]==0.5.8->mkdocs==1.2.dev1) (4.54.1)
Using legacy 'setup.py install' for mkdocs, since package 'wheel' is not installed.
Installing collected packages: mkdocs
    Running setup.py install for mkdocs ... done
Successfully installed mkdocs-1.2.dev1

E:\source\repos\Temp>pip freeze
click==7.1.2
future==0.18.2
Jinja2==2.11.2
joblib==0.17.0
livereload==2.6.3
lunr==0.5.8
Markdown==3.3.3
MarkupSafe==1.1.1
mdx-wikilink-plus==1.3.3
mkdocs==1.2.dev1
nltk==3.5
PyYAML==5.3.1
regex==2020.11.13
six==1.15.0
tornado==6.1
tqdm==4.54.1

@sbidoul
Copy link
Member

@sbidoul sbidoul commented Dec 24, 2020

@flywire the installation went via the legacy setup.py install path, which does not install direct_url.json METADATA because setuptools does not know about it. This should work if you either

  • install the wheel package before installing mkdocs
  • run pip with --use-pep517

@jay-pee
Copy link

@jay-pee jay-pee commented Jan 12, 2021

Hi all,
I also run into this problem when I tried to install a project by URL and using pip freeze afterwards. This project has a setup.py to install, which @sbidoul says is legacy. I found out that you should substitute setup.py with a setup.cfg. This is a little more work then just using the --use-pip517 flag, because I have multiple repositories in my requirements.txt that depend on URLs.

@sbidoul can you expand a little bit more on using the --use-pip517 flag. Does it have any disadvantages? Does it go deprecated soon for example? Thanks for your help.

@uranusjr
Copy link
Member

@uranusjr uranusjr commented Jan 12, 2021

setup.py itself is not legacy, only setup.py install. If you pip install wheel first, pip would use setup.py bdist_wheel instead, which is a supported code path.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C: freeze C: PEP 517 impact C: vcs PEP implementation state: blocked type: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.