I feel adventurous today. Worst case scenario, I revert from backup.
Let me know if you run into any trouble.
By the way, reverting can be done like this.
$ cd pyblish-win $ git checkout 1.0.3
during the update:
Unlink of file 'lib/pyblish-suite/pyblish-endpoint/pyblish_endpoint/vendor/wekzeug/serving.py' failed. Should I try again (y/n)
Seem to not like something.
My bad, looks like some machines had hosts running since Friday.
Files being in use is always a bit dodgy. Not much you can do, except double check permissions and that things aren’t in use, it is attempting to delete (unlink) it. The bad news for you is that you’ve probably got an inconsistent state of Pyblish now, as some files might have gotten deleted before it failed.
Something else just occurred to me, which is that
update.bat is been updated, but you are running a previous version of it. Sort of an inception going on. You will get the latest
update.bat once it finishes, but the one you’re actually running is old.
This time around, you are probably best off running the lines by hand. Try this.
cd pyblish-win git checkout master git reset --hard git pull git submodule update --init --recursive git clean -xffd
You can copy-paste all of it at once.
update.bat shouldn’t see many updates so it shouldn’t be a recurring problem.
Does this apply to repairing as well? There are a few occasions where we have
repair_instance. Should that become
Yes it does. And they are also backwards compatible.
The one caveat here is that arguments supplied to
repair() should match the ones supplied to
process(). For example, if you have
process(self, instance) then you should have
repair(self, instance). If they don’t match, you get undefined behaviour.
I’m expecting this to go away with the implementation of Actions.
update.bat, I get the following error when starting Maya:
Failed to execute userSetup.py Traceback (most recent call last): File "C:/Users/dmartine/Documents/maya/scripts\userSetup.py", line 2, in <module> init_pyblish.init() File "C:/Users/dmartine/Documents/maya/scripts\init_pyblish.py", line 7, in init import pyblish_maya ImportError: No module named pyblish_maya
This might be caused by the way we were initialising
Pyblish. Do you know what could be causing this? If you need to post me any code, let me know.
Probably due to this:
The previous root /python directory has been renamed /pythonpath
Pyblish Suite has been superseeded by Pyblish X
Inner packages are now located within /lib/pyblish-x/modules instead of /lib/pyblish-suite.
I guess you’re adding pyblish paths to you environment prior to launching maya. If so, then you’ll need to change your pythonpath to include:
Yes, probably what @mkolar said.
Otherwise, would it be possible to see your
userSetup.py? It might reveal what paths it’s looking for.
When renaming files from
_validate..., pyblish still picks them up.
Have I missed a change in the api?
Yes, there has been an undocumented change. Names don’t matter any more, you can name your files anything you want.
It’s been changed because of SimplePlugin, and I left it undocumented because it’s still a good idea to keep plug-ins named by their corresponding SVEC type.
Having a convention for temporarily disabled plug-ins could be useful though, and underscore seems appropriate. I’ll put that in. Thoughts?
Good to know they’re not dependent on name anymore (didn’t seem necessary when I first read about it anyways.), not that I wouldn’t name them the same way anyways, but one never knows.
Underscore seem like a nice way for temporarily disabling plugins. Another option would be starting the name with a dot ‘.’ That would align with unix system invisibility and would be very intuitive as well. But either will work.
Dot could work, but to me they mean “hidden but important” whereas an underscore means “internal”. Neither really says “disabled” though. Ideally, plug-ins that shouldn’t be there simply shouldn’t be there.
True. This is more of a development convenience function that would be nice, but certainly not essential. If possible and easy to implement, I’d exclude the ‘undescored’ plugins.
As long as you keep your audience in mind, it should be fine.
For example, consider this package.
└── pyblish-magenta ├── put_conceptart_in_right_location.py ├── joints_should_be_hidden.py ├── export_correct_geometry.py └── check_that_display_layers_match.py
└── pyblish-magenta ├── extract_model.py ├── validate_joints.py ├── validate_display_layers.py └── conform_conceptart.py
Ahh, didn’t think to put the files into different folder. For development I can just put unwanted plugins into a temp directory.
Updated to 1.0.5, with Pyblish 1.1.1
Here are the changes.
- Enhancement: Hosts limit, not allow (see #194)
- Enhancement: CLI outputs less, more concise information
- Enhancement: Lowering logging level for plug-ins skipped during discovery to DEBUG
- Enhancement: Underscore-prefixed plug-ins are hidden from discovery (see #196)
- Bugfix: Discover ignores non-Python files (see #192)
I have a feeling I’ve read somewhere, that you were planning to implement option to query existence of data by using
instance.data['someData'] rather than
was I dreaming, or is that working?