Open myselfhimself opened 4 years ago
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?
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.
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.
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:
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.
php bin/console
to help create new projects, list routes, list components, run component exposed new commands, create ORM tables and objectsdrush
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.wp-cli
similar to drush.yum
, apt-get
package-management tools allow to list online packages, add new package sources, add and remove packagespip
, npm
and composer
allow listing and downloading modules, listing installed modules, updating them.. npm also allows to define new shell commands.
etc...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.
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:
npm
for node)I am proposing either banana
or bpm
.
What do you think?
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?
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.
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
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
Re reading over syne comments. The get blender feature might be break out able into its own thing. Maybe
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.
Related work for testing things inside Blender: https://github.com/MaximeWeyl/blender_testing (untouched for 3 years now)
OK done an initial upload to test pypi:
https://test.pypi.org/project/blender-addon-tester/
working off this branch:
pypi-test
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
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 notifications@github.com 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 https://github.com/douglaskastle/blender-addon-tester/issues/4#issuecomment-606133471, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJU5QSQI26U256G4R2SD4LRKDIYLANCNFSM4LR3YILA .
OK preliminary release is up:
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 notifications@github.com 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 https://github.com/douglaskastle/blender-addon-tester/issues/4#issuecomment-606931611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJU5QWPG3A3YBQGFLJBYATRKJZVLANCNFSM4LR3YILA .
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.
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
README updated
Updated to v0.2 on pypi
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:
v*
eg.v0.1
tag is pushed (inspired from this workflow file and this send_to_pypi_bash_function)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