Add releases publishing onto pypi.org

[myselfhimself]

For now, we are targetting a Github branch in order for pip install blender_addon_tester to test itself.

Having blender-addon-tester written with hyphens instead of underscores prevents easy import from python, so possibly we should stick to underscores in the setup.py / python packaging as much as possible.

We should:

• decide on the name and URL on pypi.org: blender_addon_tester
• decide on a versioning. Eg. start with 0.1
• write maybe a Github Actions workflow file that pushes a release to pypi.org using Twine when a v* eg. v0.1 tag is pushed (inspired from this workflow file and this send_to_pypi_bash_function)
• make a more concise README if we plan to use the text for both the pypi.org project page and the Github project home README
• test that pip installing from upstream does work, from a local a machine and from other Github projects CIs jobs maybe.

For info, after pushing a release to pypi.org, it looks like 30 minutes-2 hours are needed before any pip install grabs that new version

[douglaskastle]

quick question should we rename everything to use underscores instead of hyphens. Or no delimiter at all? blenderaddontester (ugh!) The hyphens do seem popular in the blender addon world.

This hasn't been taken in pypi, bladt ... ? Too esoteric?

[myselfhimself]

Looking for inspiration...
Beautiful Soup is about HTML scraping and is not named html-scraping-library but something fancier indeed and this library has been famous for many years already
Here is their pypi.org page and they do import BeautifulSoup (regarding words shaping) also because the library is class oriented.

[myselfhimself]

One underground thought I have been feeding these last weeks is that the getBlender functionality, allowing to download a Blender release for any version and any OS in 1 Python command could be possibly useful in other contexts, without having software test development in mind at all.
So this is like one of the hidden pillars of the project: a Blender Version grabber, a Blender Addon tester.
Look, I will finish the Mac OS X integration first and come back to that.

[myselfhimself]

Hello I have thought over the whole tool last night and a wider vision could help more people in the future and yield and funnier name.

Taking stock.

The tool allows:

• downloading any blender version for any OS (possibly to any location on hard drive) with a local caching mechanism
• making blender evaluate any injected python script, a bit like docker
• downloading and enabling any blender add-on (for now, only from local files, but a remote repo of blender add-ons could be thought of) into any blender version installed.
• running an addon's pytest test suite and exposing any coverage report found.
• CLI use (commands are called with command line parameters)
• use as a python module for any other python script.

This reminds me of CMSes, web frameworks, make tools and OSes tools, except those do not always provide an module/library API interface, just a CLI interface.

• The Symfony web framework has php bin/console to help create new projects, list routes, list components, run component exposed new commands, create ORM tables and objects
• Drupal's shell tool drush allows to download any drupal version, bootstrap it and evaluate PHP in it in headless, download modules (ie. plugins), list drupal+module CLI commands. Drush allows the description of a Drupal installation from a recipe file: which drupal version, which patches URLs, which modules, which features (ie. serialized configuration overrides) etc.
• Wordpress has wp-cli similar to drush.
• Linux distributions yum, apt-get package-management tools allow to list online packages, add new package sources, add and remove packages
• pip, npm and composer allow listing and downloading modules, listing installed modules, updating them.. npm also allows to define new shell commands.
  etc...
• docker has its Dockerfile and docker-compose yml
• imagemagick, G'MIC are somehow image processing frameworks with very developed command lines. G'MIC allows self-updating of filters, where community filters are defined on a community github repository where people put pull requests.
  Most of those tools are cross-platform and provide command-line autocompletion.

So blender-addon-tester is absolutely not just something to test just add ons....
I have looked around if there is a sort of external blender shell/package manager but have found none.

• maybe blender-package-manager-addon, inactive since 2016
• maybe blenderpy for windows blender download and headless evaluation
• maybe BlenderUpdater, still maintained, but it is focused on blender buildbot versions.
• maybe Blender addon command line render generator, for rendering headless using a sh,bat script on any OS, but is not maintained.
• blenderkit: is a 3d assets "package manager" but is not for blender releases and addons, not headless, not CLI based etc.

[myselfhimself]

So here is my little proposal.
If we are sure there is no competitor to collaborate or do coopetition with for a sort of blender shell / package manager... let us invent something wider.

We would need a name that is easy to understand and easy to type.
Ideas:

• bcli (for Blender CLI)
• bdocker (for Blender Docker)
• bshell (Blender shell, used several times)
• blenshell (same, though very unused)
• banana (favourite fruit of suzanne) or bnana (shorter, similar pronounciation)
• suz (beginning of suzanne)
• blush (Blender Universal Shell), used many times for other projects but who cares
• bpm (Blender Package Manager, ala npm for node)
• blender-compose(r)
• bline (very much unused for technology)

I am proposing either banana or bpm.

What do you think?

[douglaskastle]

OK, let's slow down a second. I love every thing you said, but I want to watch out for feature creep. The goal of my work was to enable addon testing only. Nice and simple. You say:

So blender-addon-tester is absolutely not just something to test just add ons....

Well actually that's exactly it is! KISS! Remember the people who I/we want to use it are probably not software developers. Not even script kiddies, think about them, and how they might use something, not how you might use it.

However there is no reason why it can't sit inside something else that does what you say. I suspect this is a different project, with a different repo, that might pull a load of sub repos/projects together.

I obviously don't have the bandwidth at the moment and it does look like a lot of work.

Would you even have time to service this work, is it not out side the scope of what are your requirements?

[myselfhimself]

Hello I must indeed prioritize making gmic-py cross platform and finish numpy i/o support for it.
I would like to finish adding the macos support for blender-addon-tester it this week and the pypi.org releasing can happen anytime without hurry.
Maybe we can think about this other bigger project later indeed.

[myselfhimself]

blender-addon-tester is an ok name
it could be pip installable as blender-addon-tester
but importable as blender_addon_tester because the shipped files are so

I am open to any alternative you would like

[douglaskastle]

i am not too invested in the name, and can't think of anything better to warrant holding up this effort. If a change was required now would be the best time to do it is all.

Lets go with that

[douglaskastle]

Re reading over syne comments. The get blender feature might be break out able into its own thing. Maybe

[myselfhimself]

would you mean a different repository ? a different pypi.org project ?
if so, blender-addon-tester could be a user of some other blender-downloader python module
pypi.org administration is not hyperfunny, I would rather not a open a project there if it is aimed to be deprecated soon, so I would rather have one pypi.org project for both actions (test addons, download blender) and called to grow with more commands, such as this blender-package-manager idea... though this pypi.org project could be created much later. If so, we can live with one or more github projects tied by pip install giturl dependency calls longer eg. gmic-blender -> blender-addon-tester -> blender-downloader and same for your lightwave addon project in place of gmic-blender.

[myselfhimself]

Related work for testing things inside Blender: https://github.com/MaximeWeyl/blender_testing
(untouched for 3 years now)

[douglaskastle]

OK done an initial upload to test pypi:

https://test.pypi.org/project/blender-addon-tester/

working off this branch:

pypi-test

[douglaskastle]

Recommend pushing current work to pypi manually so that reference links can be updated. Can come back to documentation and automation later.

I want to use this work on another project and what that project referencing this one in the final manner

[myselfhimself]

Hello no problem. I do not understand well those reference links you mention, though maybe this is not very important for me to understand. Just, releasing is not easy because it usually needs 1 very specific command with possibly tokens as parameters or environment variables. For releasing another python project to pypi from github, here is my setup: the secret tokens are generated by pypi.org in a management interface, then stored as secrets inside github for the given repository, then place holders for those secrets are used within a .github actions job (that could be restrained to on-tag-push-only) leveraging twine, where the github runner automatically replaces those secrets with their proper contents. So in the end, maybe a script file might be interesting to have in the project for releasing (or could a subcommand of a all-rounder management script file), that any maintainer could run for any release. Apart from that, I am not in a hurry at all :) po 30. 3. 2020 v 19:25 odesílatel Douglas Kastle <[email protected]> napsal:

…

Recommend pushing current work to pypi manually so that reference links can be updated. Can come back to documentation and automation later. I want to use this work on another project and what that project referencing this one in the final manner — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJU5QSQI26U256G4R2SD4LRKDIYLANCNFSM4LR3YILA> .

[douglaskastle]

OK preliminary release is up:

https://pypi.org/project/blender-addon-tester/

[myselfhimself]

perfect, thank you, managed to pip install, managed to import blender_addon_tester managed to run BAT.test_blender_addon managed to uninstall I will want if you do not mind to have either a simplified README for the pypi.org project. It can be used for github as well or not. I had ideas for the docs/ already.. just trying to avoid multi-tasking myself for now Sorry if I take 3 weeks to start comitting again st 1. 4. 2020 v 1:08 odesílatel Douglas Kastle <[email protected]> napsal:

…

OK preliminary release is up: https://pypi.org/project/blender-addon-tester/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJU5QWPG3A3YBQGFLJBYATRKJZVLANCNFSM4LR3YILA> .

[douglaskastle]

Yeah still need to trim the readme, I wanted to get fake-addon up and running and understand how to split the existing content between the two. So currently getting that going I think I see a few edits now that they are split.

My input over the next few weeks will likely be sporadic. What ever your input is great and appreciated and I understand if your work and life take precedence.

[douglaskastle]

Rewrote blender-fake-addon documentation and test flow to reflect the new setup

https://github.com/douglaskastle/blender-fake-addon

still needs to be bulked up for github actions and coverage

[douglaskastle]

README updated

[douglaskastle]

Updated to v0.2 on pypi