as I was preparing some scripts I’ve written in the past to be released to public, it got me thinking about the way be share scripts and what standards and guidelines we follow.
Since python support is relativly new in Flame we are still far away from where the Nuke community is. But with more controll coming with each release and more and more people getting into the python side of Flame, I think now is a very good point to start a discussion about how we want the whole thing to be.
There are several points that got me started thinking about all this and I would love to hear your thoughts about it!
Coding style:
This is something that I’ve ignored for a long time myself (especially because it didn’t matter to me when I started with python). But whenever I look into old scripts now, it is hard to understand what I did there. Even if I get it, the code is unpleasing to read due to bad formatting and really no fun to update.
Even Autodesk didn’t bother in the early versions of the api, when every hook was written in camel case. Fortunatly this changed a while ago and everything is now repecting PEP8. So in a perfect world every script we share would do this, so it’s easier for other to do changes if needed.
Menu management
In most scripts that I’ve seen, the menu items calling the script are defined inside the same file as the script. This might work for now, but I do see a big problem here for the future when more and more scripts are added (especially since we can’t create any submenus yet). This will quickly become very unorganized. I think we can learn from the Nuke world here, where it has become common practice to separate these things:
—> some_awsome_script (folder)
-------> some_awesome_script.py
-------> menu.py
In this case “some_awesome_script.py” would only contain all the logic, while “menu.py” would import the script as a module and create the menu items. This has the great advantage that everybody can modify the menu to his personal (or company’s) needs and doesn’t break anything if the actual script is updated / overwritten.
Sharing of scripts
I think logik portal is a great way of sharing scripts (thanks Mike for all the efford!), especially for users who are just starting to touch the python world and don’t have much experience in setting things up manually. Nevertheless I currently wouldn’t use it myself due to security concerns (no offence! I just think nobody has thought about this scenario yet). I think it’s not a smart idea to write details about this in public, so let’s have a private chat if you like.
I wonder what happend to the official github repository from Autodesk. It looks completely abandoned. No updates since 2 years and most of the script that existed there in the past are gone now. It feels as if there were only 2 or 3 scripts left. @fredwarren can you shed some light on this?
I wonder why nobody uses this to share scripts. It’s also implemented directly in Flame. The only thing I miss, is the ability so see the readme.md files inside Flame’s browser. But besides that, I think it has some advantages over the logik portal, like version controll, a web ui to browse scripts, thanks to git easy to maintain a local install with updates, even in a custom (centralized) location etc.
I would assume that the limiting factor for artists using it may be git, because most people who are just starting with python may not know about the usage of it.
I know the logik portal does more than only sharing python scripts. So why not make it wrapper of the github repo instead of the ftp server? This would also eliminate the security concerns. @MikeV what do you think?
As I already said I’m really looking forward to your input on these topics.
Thank you for starting this thread! I feel the same way re: looking back at my old scripts. I’m still very much an amateur…I don’t know what PEP8 is, and I’m gonna guess that camel case is when you call a variable something like “camelCase”? If so I’m definitely guilty.
Would love to get a convo going here with the other folks who are into python. I think the biggest thing is that someone has to own the standard: Someone has to write it up and modify as needed, and someone needs to validate the uploaded/shared scripts.
As a complete Python novice I have no idea what the way forward is. However, I am passionate about understanding what the community wants and delivering solutions.
There are, from the top of my head, less than a dozen or so of us that are active writing Python tools. So, all we need are a few people to get together, figure out what makes sense and do it.
I’m also passionate about this being something that we as a community can decide, build, operate and sustain.
PEP8 demonstrates the preferred way to write python scripts.
It’s not difficult to understand, but it’s thorough, takes a little while to read & may conflict with how you learned to write scripts,
My colleagues that know C or C++ scoff at the formalities and the long winded ness and the hand holding.
Personally, I like all lower case separated by underscores, and I like extensive comments, and I like breaking wallpaper size scripts into tiny napkin size chunks, and saving out the functions, modules and packages separately.
Also, my dumb python scripts don’t necessarily benefit from being able to compile and execute in a quarter of a pico second.
@andymilkis yes, that’s camel case.
If you’re building a gui with PySide or PyQt there are many situations where you can’t stick to PEP8 and have to write functions in camel case, because Qt does not have it’s origin in the python world. So inheriting functions from there will always mess up the otherwise nice looking code.
Besides that I always try to follow PEP8 as it will really help to enhance the readability of your code.
The really nice thing is, that if you’re not just using a super simple text editor but any IDE (personally I’m a big fan of PyCharm, which is available for free as a community edition) it will come with different tools to support you on this mission. E.g. PyCharm will check your code live to be compliant with the PEP8 rules. It will underline anything that is not ok, give you more information about if you hover the mouse over it or run a check on the entire script and print out the test result. That way you can just learn the rules while coding and don’t have to know all rules up front.
It also integrates nicely with Git and other versioning systems. Even though I really like to code, I’m not a big fan of handling everything from the command line. In PyCharm adding and commiting your changes to GitHub are just one click away. No need to dive into the deep rabbit hole of possible command line options.
I don’t want to do heaving advertising on this particular piece of software, since there are a lot of others out there. That’s just the one I’m most familiar with.
As Randy said, I think there are currently only few people actively pushing things to the community. That’s why I thought now is the perfekt time to get together and setup some guidelines that work for everybody.
@philm I also like to write all lower case separated by underscores. I think I haven’t found the perfect dose of docstrings yet, as it often feels strange to me writing more lines of docstrings than the actual function. Besides that I try to provide enough comments.
You bring up some good points. I agree the menu’s could be managed better. I think the ability to add menu’s as either a top level menu item or the ability to add additional layers of sub-menu’s would go a long way. Maybe we’ll get that one day. @fredwarren
Thanks to a little guidance from @panisset, I started messing around with github a bit this week. I set up a repository with a bunch of the flame qt ui elements that I’ve made for buttons, menus, and a few other things. Hopefully I’ve done it the right way. GitHub - mikev-pyflame/flame_qt_ui_widgets: Flame like QT UI elements
After playing around with it a bit I think using github to submit scripts for the portal is a pretty good idea. Maybe we could start up a Logik repository that a few of us could help manage. The Portal could then pull scripts from that repository.
I think having a github repository (which may then be loaded by the portal) would be the most elegant way to do it.
I’m still very interested to hear what @fredwarren can say about the official github repo.
I think there are some pros and cons of using the official repo and having a community driven repo:
Using the official repo would (hopefully) guarantee a high quality standard of all scripts, which may be harder to reach if this is done by the community. On the other hand it may slow things down a lot if the Autodesk employees are too busy with other stuff than reviewing our latest commits. A community driven repo could be better in this case.
To be honest: I’m unsure at this point which one is the better route.
PS: Thanks Mike for sharing the qt widgets! Have you tried already to integrate them into qt designer? Would be super nice to speed up the designing process up a bit.
