On 21 May 2015 at 23:49, Chris Barker <[email protected]> wrote:
> On Thu, May 21, 2015 at 1:12 PM, Paul Moore <[email protected]> wrote:
>> Some possible problem areas - when you install a wheel, it will
>> install executable wrappers for the entry points (like pip.exe) which
>> are tied to the install location. You'd need to deal with that. But
>> presumably conda already has to deal with that because setuptools does
>> precisely the same.
>
> indeed conda build (or is it install -- not sure!) does do path re-writing,
> etc.

Note that script wrappers are executables, not scripts, (some are exes
with scripts alongside, but not all - distlib and pip embed the script
in the exe). So simply editing scripts in .py files isn't enough.

>> > I'm still a bit confused about the role of wheel here. Why build a
>> > wheel,
>> > just so you can go install it, rather than simply install the package
>> > directly?
>>
>> Basically, because you can't "simply install". You may not have a
>> compiler, or you may not have the required libraries, etc etc.
>
> I'm thinking of the context of building a conda package -- or rpm, etc. --
> not the general, "you are using pip as your package manager" case. And in
> that case, you want to build it to match your environemnt -- which may not
> be what a wheel onPyPi matches, for instance.
>
> So you have to build the package -- not sure what that wheel step buys you.
> But it doesn't cost much either, so why not?

It avoids the need to embed the knowledge of how to build the package
in conda. Remember that "setup.py install" is not necessarily the only
way a package might be built once we get to the pluggable build state.

>> Generally, pretty much all of the reasons people don't compile all
>> their software on their production machines :-)
>
> right, but you're not running conda build on a production machine, either.

I was answering your question "why install from wheels rather than
just installing directly". Now that I understand that you're saying
"... in the context of building conda packages" the answer is slightly
different:

- To prepare for a "pluggable build" situation.
- To integrate better with the rest of the Python packaging world.
- To let people without compilers, but with access to binary wheels,
build their own conda packages should the official ones not exist.

(possibly others, that's just off the top of my head).

Paul
_______________________________________________
Distutils-SIG maillist  -  [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to