iter_metadata would unexpectly find another package's metadata

[frostming]

requirementslib/src/requirementslib/models/setup_info.py

Lines 455 to 473 in d252fd0

	def iter_metadata(path, pkg_name=None, metadata_type="egg-info"):
	# type: (AnyStr, Optional[AnyStr], AnyStr) -> Generator
	if pkg_name is not None:
	pkg_variants = get_name_variants(pkg_name)
	non_matching_dirs = []
	with contextlib.closing(ScandirCloser(path)) as path_iterator:
	for entry in path_iterator:
	if entry.is_dir():
	entry_name, ext = os.path.splitext(entry.name)
	if ext.endswith(metadata_type):
	if pkg_name is None or entry_name.lower() in pkg_variants:
	yield entry
	elif not entry.name.endswith(metadata_type):
	non_matching_dirs.append(entry)
	for entry in non_matching_dirs:
	for dir_entry in iter_metadata(
	entry.path, pkg_name=pkg_name, metadata_type=metadata_type
	):
	yield dir_entry

iter_metadata() scans metadata that ends with given pattern inside a path recursively, which would return unexpected results in some cases, here is the directory tree of one:

├───.venv    # We have a .venv folder here
│   ├───Include
│   ├───Lib
│   │   └───site-packages
│   │       ├───pip
│   │       ├───pip-19.0.3.dist-info   # pip metadata will be returned
├───src
│   ├───requirementslib
...

Testing:

r = requirements.Requirement.from_line('-e .')
print(r.ireq)

The possible solution is to change the DFS method to BFS.

[uranusjr]

I don’t have time to read the actual PR implementation, but using BFS sounds like the correct idea.

[techalchemy]

I believe I had this implemented at one time and it was terribly broken, but I could be mistaken. at a glance it seems right