[Soc-2016-dev] Hello and a quick status update

[Campbell Barton]

First of all, there have been some GUI front-ends to pip, though not many.
One I found called stallion [0] which looks nice, though I couldn't
get it working - starts a server but the web-page just shows an
internal server error, no hints in the console that anything failed.

There is also a library called Esky which abstracts packaging functionality [1].

While a bit dated (2014), this post is from a Nick Coghlan, a Python
core developer,
talking about the difficulty of having a gui front-end to pip [2].

One complication with using pip, is that its primarily a command line
application, not a library *.
it may ask the user for keyboard input in the terminal for example **.
Error messages are quite technical too (since this tool is mainly used
by Python developers).

Of course with Python you can load in pip as a module and replace
function calls... but there is quite some room for errors here (error
states need to be communicated to the user without simply showing them
stack-traces and hoping they can troubleshoot it themselves).

---

The other side of this is the barrier of entry for developers, see tutorial [3].
This isn't an argument *against*, just that we should consider it when
evaluating pip.

---

Using pip may be fine, as long as common errors *** can be handled
without users needing to learn how to troubleshoot pip themselves.

---

*) while it can be imported as a module, this would still be writing a
front-end to a command line tool.

**) PIP_NO_INPUT environment variable can be set, however this will
raise an exception if pip asks the user for input.

***) network-disconnection, file-permissions, disk-full, version
incompatibilities with blender.

[0]: http://perone.github.io/stallion/
[1]: https://github.com/cloudmatrix/esky/
[2]: https://github.com/pypa/packaging-problems/issues/57#issuecomment-63204553
[3]: http://python-packaging.readthedocs.io/en/latest/minimal.html

On Wed, May 4, 2016 at 2:50 AM, Sybren A. Stüvel <sybren at stuvel.eu> wrote:
> On Mon, May 02, 2016 at 02:02:57PM -0300, Sebastian A. Brachi wrote:
>> * Installation of addons: currently addons are simply stored in a
>> defined path. I always wondered why[1] they are not simply installed
>> in dist-packages, like any other libs.
>
> For one, the addons are recognised by their bl_info dict. To obtain
> the list of available addons, their code isn't imported & executed,
> but it is parsed by Blender without execution. This is easier if they
> are in a well-known location, rather than having to search all
> possible installation locations that Python has available.
>
> I think that changing this is out of the scope of Peter's GSoC
> project.
>
>> * dependency management: another limitation I find in the current
>> add-on development process is that to include any dependencies the
>> add-on has to include them in the repo itself. Using pip and
>> distutils could help solve this. If I remember correctly, 'requests'
>> was included in blender because many scripts needed it, but of
>> course tat doesn't scale.
>
> It would be very nice if we could have automatic downloading of
> packages, for example based on a requirements.txt for each addon.
> However, this would change the structure of addons (this wouldn't be
> possible with single-file addons, for example).
>
> Currently, for the upcoming Blender Cloud addon, we bundle wheel files
> with the addon itself. Those wheels are only loaded if the package
> can't be regularly imported by Python. For more details see
> https://developer.blender.org/diffusion/BCA/browse/master/
>
> Cheers,
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
> _______________________________________________
> Soc-2016-dev mailing list
> Soc-2016-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2016-dev
>



-- 
- Campbell