Hello John,

On 13/4/21 1:15 pm, John Rouillard wrote:
> 
> John Rouillard added the comment:
> 
> Hi John:
> 
> In message <6bc554a3-c2ca-e9d3-1250-5a2aea397247@jerrykan.com>,
> John Kristensen writes:
>> On 12/4/21 1:42 pm, John Rouillard wrote:
>>>>> [...] I also did a pure sdist and tested the tarball. All
>>>>> tests passed.
>>>>>
>>> What is the equivalent test mechanism for an egg or wheel to verify
>>> that they are properly built and will install correctly.
>>> E.G. a dummy example would be:
>>>
>>>      python --wheel roundup.whl --entry roundup-admin
>>>
>>> to verify that I can start roundup-admin from the wheel.
>>>
>>> Roundup isn't just a module to be imported by an application. It is a
>>> set of cli applications, so maybe egg/wheel distribution doesn't make
>>> sense.
>>
>> Would the following commands cover the use-cases for testing the
>> installation from the various file formats:
>>
>>      pip install dist/roundup-2.0.0.tar.gz
>>      pip install dist/roundup-2.0.0-py3-none-any.whl
>>      python -m easy_install dist/roundup-2.0.0-py3.9.egg
>>
>> I'm not sure about how to invoke commands from a python archives
>> directly. Are there any specific use-cases where this would be useful? I
>> would assume to do anything useful with roundup it would need to be
>> installed.
> 
> I am not sure. Does distributing wheels and eggs for roundup make any
> sense? I thought wheels and eggs were an installation method. However
> it looks like using wheels and eggs only make sense for code that
> consists only of modules to be imported. If the package has command
> line code (e.g. roundup-server, roundup-admin) then distributing
> wheels or eggs is worthless.
> 
> That being said we do have some client side roundup libraries that are
> meant to be used by roundup users writing their own code. E.G. the
> xmlrpc client, see: https://issues.roundup-tracker.org/issue2550554.
> I could see an equivalent REST library joining it in the future.
> 
> Am I interpreting the utility of egg/whl correctly?

My understanding is that a tarball is source distribution while a wheel 
in more like a binary distribution. For a python package that contains C 
code, installing from a tarball will require having a compiler 
installed, while installing from a wheel doesn't (because the code has 
already been pre-compiled).

For a native python package there probably isn't isn't a whole of 
difference, but is sounds like pip will still convert the tarball to a 
wheel first, then install the wheel.

So I there there is value in providing both tarballs and wheels.

Wheels are intended to replace eggs, so I think we can just ignore those.