Originally reported by: Michele Lacchia (Bitbucket: rubik, GitHub: rubik)

We should follow PEP8, using tools like pep8, autopep8, pylint.
I can take care of this, if you agree.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/10

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/19

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

See the fallback in bdist_wheel.py

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/26

Originally reported by: Marc Abramowitz (Bitbucket: msabramo, GitHub: msabramo)

1. Remove the hard-coded path to file:///home/dholth/prog/wheel

2. Add --build to pip install line so that it creates and populates build directory.

   --- a/wheeldemo.sh Wed Jul 04 21:52:49 2012 -0400
   +++ b/wheeldemo.sh Wed Jul 04 21:30:57 2012 -0700
   @@ -2,13 +2,14 @@

   bdist_wheel demo

   Create environment

   virtualenv /tmp/wheeldemo
   +SRCDIR=$(pwd)
   cd /tmp/wheeldemo

   Install wheel and patched pip, distribute

   -bin/pip install -e hg+file:///home/dholth/prog/wheel#egg=wheel -e hg+https://bitbucket.org/dholth/distribute#egg=distribute -e git+https://github.com/dholth/pip.git#egg=pip
   +bin/pip install -e $SRCDIR -e hg+https://bitbucket.org/dholth/distribute#egg=distribute -e git+https://github.com/dholth/pip.git#egg=pip

   Download an unpack a package and its dependencies into build/

   -bin/pip install --no-install pyramid
   +bin/pip install --no-install --ignore-installed --build build pyramid
   cd build

   Make wheels for each package

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/5

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

The CSV module specifies that open files passed to the module constructors must be opened with newline='' (Python 3) or 'b' in the mode (Python 2). The bdist_wheel command does not do this, and as a result can create corrupt CSV files with invalid line endings (most often \r\r\n). The attached patch uses the correct mode (it provides a helper function to open the file correctly whether Python 2 or 3 is being used).

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/16

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

wheel stores scripts with #!python as the first line. Needs to be updated to point to the correct interpreter during install time.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/6

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

I have a Python 3.2 virtualenv with the patched pip and distribute installed, and the wheel installation. I tried to test bdist_wheel by creating a wheel of Pygments, and I got the error

#!python

>D:\Data\Wheel\WH\Scripts\python.exe .\setup.py bdist_wheel
running bdist_wheel
running build
running build_py
installing to build\bdist.win32\wheel
running install
build\bdist.win32\wheel

Traceback (most recent call last):
  File ".\setup.py", line 87, in <module>
    **add_keywords
  File "D:\Apps\Python32\Lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "D:\Apps\Python32\Lib\distutils\dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "D:\Apps\Python32\Lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "D:\Data\Wheel\WH\lib\site-packages\wheel\bdist_wheel.py", line 147, in run
    self.run_command('install')
  File "D:\Apps\Python32\Lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "D:\Apps\Python32\Lib\distutils\dist.py", line 935, in run_command
    cmd_obj.ensure_finalized()
  File "D:\Apps\Python32\Lib\distutils\cmd.py", line 107, in ensure_finalized
    self.finalize_options()
  File "D:\Data\Wheel\WH\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\install.py", line 29, in final
ize_options
    _install.finalize_options(self)
  File "D:\Apps\Python32\Lib\distutils\command\install.py", line 389, in finalize_options
    'scripts', 'data', 'headers')
  File "D:\Apps\Python32\Lib\distutils\command\install.py", line 551, in change_roots
    setattr(self, attr, change_root(self.root, getattr(self, attr)))
  File "D:\Apps\Python32\Lib\distutils\util.py", line 226, in change_root
    if path[0] == '\\':
IndexError: string index out of range

I haven't been able to analyze this fully, but it looks like a case of code using POSIX-style paths on Windows. In particular, the change_root code has just done os.splitdrive on a path which, as far as I can tell, is not an absolute Windows path (i.e., it has no drive letter).

As I said, I haven't been able to fully analyze the code paths, but I would suggest looking for cases where non-absolute (or artificial) paths are passed to code expecting absolute paths.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/4

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

the wheel executable "wheel sign", "wheel install" etc. needs better code coverage.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/50

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

'wheel install' should warn if it is installing a package that has already been installed. It does not know how to uninstall the conflicting package. It's not a big deal that there is no 'wheel uninstall', as the tool is designed mostly as a reference and bootstrapping tool.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/48

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Will be JSON JWS-JS format Ed25519 signatures against a sha-256 hash of RECORD (or another suitable manifest).

Must include sophisticated trust management e.g. normally you might trust your own key for every distribution, and trust other keys per distribution.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/11

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

not-zip-safe, empty entry_points.txt, dependency_links.txt, SOURCES.txt

not sure about top_level.txt

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/24

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

setup.cfg should contain a section

[wheel]
tags = ...
universal = true
?

Need to be able to generate the non-default tags:

cp32-abi3-win32

and

py2.py3-none-any

The "universal Python" tag is easier because it doesn't depend on the build platform at all, while the "uses the stable ABI" tag does.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/43

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/30

Originally reported by: Michele Lacchia (Bitbucket: rubik, GitHub: rubik)

Where to upload wheels? I tried to upload one to PyPI and got a failure, because PyPI checks the type of the distribution and fails saying the distribution is unknown.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/21

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

In the signatures JSON, writes sha256=b'abcdefg' instead of sha256=abcdefg

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/31

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Three different things that need to be documented separately.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/41

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

The setup.py file opens README.txt and CHANGES.txt in the default encoding. On Windows under Python 3, this can fail with encoding errors, as the files are in UTF-8 but that is not the default encoding.

The attached patch explicitly uses the UTF-8 encoding. It uses the codecs module for backward compatibility.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/15

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

The distribution name used to locate the egg-info file is taken from the archive (bdist_wininst or egg) name, using the standard egg/wininst naming conventions. However, it is possible for the archive to be named differently (presumably as a result of renaming, although the file naming conventions for wininst files are not formalised, so there may be other reasons for this to happen - evidence suggests that underscores in distribution names may be an issue).

In this case, the error message produced by bdist_wheel is an uninformative IO error, because the expected PKG-INFO file does not exist.

The attached patch offers a better error message, reporting both the expected filename and what was found. The user can then rename the archive as needed.

(A better solution may be to treat the egg-info file within the archive as definitive, rather than the archive name, but that would need a more extensive refactoring of the code, and may not even be practical).

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/20

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Should be possible to find the rest of the docs from a casual inspection of README

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/49

Originally reported by: Michele Lacchia (Bitbucket: rubik, GitHub: rubik)

bdist_wheel}}} stopped working. I tried building with both my fork and yours and the result is the same:
{{{bdist_wheel

#!bash

error: dist/pyg-0.7.1-py27-noabi-noarch.whl: No such file or directory

On the other hand, the PyPI copy was fully working. I then tracked down the cause and discovered that the error is due to this line:

#!python

wheel_name = archive_wheelfile(pseudoinstall_root,
                                       archive_root)

By replacing it with these two lines (as in PyPI copy):

#!python

filename = self.make_archive(pseudoinstall_root, self.format,
                                                root_dir=archive_root)
wheel_name = filename[:-3] + 'whl'

everything works again. So now we can either restore the original code or try to detect the error in archive_wheelfile.
May I ask why that line has been changed?

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/14

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/3

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

scripts should not store the full path to python-at-build-time

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/2

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

The wininst2wheel command currently gets metadata from the installer filename. However, that filename could be wrong (as it is OK to rename the installer without affecting its operation). In this case, the wininst2wheel command fails because it cannot locate the egg-info file embedded in the installer archive.

To avoid this issue, the attached patch inspects both the installer filename and the egg-info filename. It chooses the name, version, pyversion and architecture metadata values based on the "best" of the 2 sources (see the parse_info function and its docstring for details).

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/23

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

The wheel installer knows how to find wheels from a directory on the file system. That is perfect for a simplest-thing-that-could-work solution like wheel, but it would also be nice to be able to get wheels from a package index.

Define an entry point

[wheel_finder]
unimportant_name = module.name:callable

The wheel_finder's job is to convert a list of requirements (with environment markers? or without??) into a list of wheels, or the URL of a wheel, or dump those into a directory full of wheels (pick one; which is easiest?)

The example wheel finder will invoke pip with the list of requirements, pip will either download wheels from pypi or convert sdists to wheels, and wheel can install them. The example might need to go into a different pypi package.

It is a little bit tricky to define the correct plugin point for getting the wheels we would like to install. wheel-from-packagename is the simplest, but builders like pip have a ton of options regarding which indexes to search etc. (thank goodness for environment variables; perhaps the finder could expose its options on our command line too). It is possible that this kind of abstraction would be limiting, but it is simple and would certainly work most of the time.

It would also be possible to behave like make and define an entire pipeline of installer plugins:

detect whether a URL is a supported package type

find package URL

build package (adapt sdists to wheel, adapt wininst to wheel, adapt egg to wheel)

... and even install package, in case someone prefers to install wheels differently.

This kind of abstraction, with configurable plugins and a fixed pipeline structure, runs the risk of confusing everyone, or creating a "knobs with knobs" interface where you have to write a plugin for the plugin to make it work.

You could implement the second pipelined-package-discovery design on top of the wheel-from-packagename design, so we'd best try the simple idea first.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/45

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

should always be replaced with _

It's possible to parse these package names anyway, but too clever.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/9

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

python wheel-0.9.4-py27-none-any.whl/wheel install wheel-0.9.4-py27-none-any.whl should work.

It works on Linux with the latest unreleased code, but has trouble on Windows.

May need to include pkg_resources.py (packaging database implemementation) for bootstrapping.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/40

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

With all the binary/unicode wrangling, it might be a lot easier to use b'' and u'' strings throughout, and require Py33 (and Py26, Py27).

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/32

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

If a namespace has been declared with setuptools and we are using Python 3.3+, we should be able to delete init.py. This would be an installer feature.

Pretty much all the init.py get imported when pkg_resources builds the index of all the installed packages, which it does while it is being imported.

Deleting namespace init.py in Python 3.3+ removes a common use of pkg_resources that causes an unnecessary dependency on pkg_resources.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/46

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

I think the tox test runs load code from pwd instead of .tox/envname/..., so if something is omitted from the sdist the tests may still pass.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/37

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

The conversion utilities for creating wheels from eggs and bdist_wininst installers are provided as Python scripts, but not as utility commands. The attached patch adds entry points which generate executables egg2wheel and wininst2wheel, to make these 2 commands more accessible.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/17

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/29

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

It's a little bit annoying that the wheel still requires pkg_resources to run, in case you don't have it installed yet.

Instead, wheel should include wheel/pkg_resources/... and only use it if the system pkg_resources is not available (or is too old -- does not contain DistInfoDistribution). Then you can use wheel to install distribute.

We will need a script only included in the sdist to update pkg_resources from the latest release of distribute. We will need to include two copies, one with 2to3 already run.

pkg_resources may need a couple of small patches to import _markerlib (used for .dist-info conditional dependencies only) from .. instead of from the top level.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/44

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Figure out how to pass qualified requirements

argparse; python version < '2.7' # not the exact syntax

to bdist_wheel. To be included verbatim as Requires-Dist: lines.

Maybe easier to add to setup.cfg than setup.py

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/39

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Wheel's own README.txt, which winds up in METADATA via PKG-INFO, contains Unicode. When running bdist_wheel on wheel, this fails with a 'cannot encode to ascii' error:

pkg_info = Parser().parse(open(pkginfo_path, 'r'))
Generator(metadata, maxheaderlen=0).flatten(pkg_info)

Seems to be pretty much why policy= was introduced for e-mail in Python 3.3, but we would like to support older versions too.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/25

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

The wheel extensions will be part of Metadata 1.3, not an edited Metadata 1.2. Update bdist_wheel to write 1.3 instead of 1.2.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/35

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Sorry Baker, you're much cooler, but argparse is in the stdlib.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/38

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

An important part of wheel is to prefer

somepackage-1.0-cp27-noabi-linux_x86_64.whl

to somepackage-1.0-py27-noabi-noarch.whl

when you are running CPython 2.7 on linux_x86_64. This will work by looking up the compatibility tuple (impl, abi, arch) -> ranking and sorting by ranking. An installer will rank each of the (python impl, abi, architecture) triples it supports, rank all the wheels of the desired package version, and install the most highly ranked one.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/7

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

bdist_wheel creates a .zip and moves it to .whl; on Windows, may need to delete the .whl first or the move operation will fail.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/8

Originally reported by: Michele Lacchia (Bitbucket: rubik, GitHub: rubik)

bdist_wheel}}} stopped working. I tried building with both my fork and yours and the result is the same:
{{{bdist_wheel

#!bash

error: dist/pyg-0.7.1-py27-noabi-noarch.whl: No such file or directory

On the other hand, the PyPI copy was fully working. I then tracked down the cause and discovered that the error is due to this line:

 #! python

wheel_name = archive_wheelfile(pseudoinstall_root,
                                       archive_root)

By replacing it with these two lines (as in PyPI copy):

#!python

filename = self.make_archive(pseudoinstall_root, self.format,
                                                root_dir=archive_root)
wheel_name = filename[:-3] + 'whl'

everything works again. So now we can either restore the original code or try to detect the error in archive_wheelfile.
May I ask why that line has been changed?

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/12

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

In setuptools version qualifiers are not (parenthesized), but in Metadata 1.2 they are.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/1

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

I think the submodule needs to be added to setup.py or the manifest.in

Also got some complaints during install about *.o (may need to remove them from a manifest)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/34

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

It is valid in a zip file for directory entries to occur. So, for example, a bdist_wininxt file can contain either of the following two layouts:

PLATLIB/xxx
PLATLIB/yyy

or

PLATLIB/
PLATLIB/xxx
PLATLIB/yyy

The latter only differs in having an (unnecessary) entry for the PLATLIB directory itself.

The code in bdist_wininst2wheel around line 37 manipulates the ZipFile internals to rename the files in the zipfile to remove the PLATLIB (or whatever) prefix. Unfortunately, in doing this, it converts the "PLATLIB/" entry to have a 0-length name. This is not valid, and the extractall method fails (with an "index out of range" error as a result.

This problem actually occurs, in the scipy installer distributed by Christoph Gohlke.

The attached patch fixes this by creating an explicit list of members to extract and ignoring empty items.

(Note that hacking the internals of a ZipFile object like the original code does is not documented, and so is probably very fragile, but I cannot see an easy way of achieving the same result using documented methods...)

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/18

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Although it won't be able to sign.

It should be very common to install wheel by itself (just to get bdist_wheel in a virtualenv) without the sign/verify (os.system(/usr/bin/wheel) to sign and verify).

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/33

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Need code to locate & create ~/.local/wheel/wheel.conf plus overrides in environment variable

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/28

Originally reported by: Michele Lacchia (Bitbucket: rubik, GitHub: rubik)

bdist_wheel}}} stopped working. I tried building with both my fork and yours and the result is the same:
{{{bdist_wheel

#!bash

error: dist/pyg-0.7.1-py27-noabi-noarch.whl: No such file or directory

On the other hand, the PyPI copy was fully working. I then tracked down the cause and discovered that the error is due to this line:

 #! python

wheel_name = archive_wheelfile(pseudoinstall_root,
                                       archive_root)

By replacing it with these two lines (as in PyPI copy):

#!python

filename = self.make_archive(pseudoinstall_root, self.format,
                                                root_dir=archive_root)
wheel_name = filename[:-3] + 'whl'

everything works again. So now we can either restore the original code or try to detect the error in archive_wheelfile.
May I ask why that line has been changed?

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/13

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

Many open source licenses require the license to be included with every copy of the program. bdist_wheel should copy the license into .dist-info/ if it can.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/47

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

The wheel tool should have an "unpack" command that creates a name-version/ folder and then unpacks the archive (will later verify the archive's RECORD hashes and digital signatures). Contrast to "unzip archive.whl" which would put everything in the current directory.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/27

Originally reported by: Andrii Mishkovskyi (Bitbucket: mishok13, GitHub: mishok13)

I've been playing with wheel recently and decided to try out the wheel command, but it gives the following error:

$ wheel install
Traceback (most recent call last):
  File "/usr/local/bin/wheel", line 9, in <module>
    load_entry_point('wheel==0.9.3', 'console_scripts', 'wheel')()
  File "/Library/Python/2.7/site-packages/wheel/__main__.py", line 6, in main
    import wheel.tool
  File "/Library/Python/2.7/site-packages/wheel/tool/__init__.py", line 9, in <module>
    import wheel.install
  File "/Library/Python/2.7/site-packages/wheel/install.py", line 22, in <module>
    from wheel import signatures
ImportError: cannot import name signatures

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/36

Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)

when requires.txt includes

[testing]
zope.component[hook]

the bdist_wheel parser drops [hook] before writing to METADATA

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/42

Originally reported by: Paul Moore (Bitbucket: pmoore, GitHub: pmoore)

When the target file exists on Windows, os.rename fails. This causes wininst2wheel to fail if the wheel file already exists. The same problem exists in egg2wheel.

The attached patch fixes this by explicitly deleting the target before the rename, if it exists.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/22