Pyblish 1.1 Released

Announcement
#5

I feel adventurous today. Worst case scenario, I revert from backup.

#6

Let me know if you run into any trouble. :slight_smile:

By the way, reverting can be done like this.

$ cd pyblish-win
$ git checkout 1.0.3
#7

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.

Edit:
My bad, looks like some machines had hosts running since Friday.

#8

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.

#9

Does this apply to repairing as well? There are a few occasions where we have repair_instance. Should that become repair?

#10

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.

#11

After using 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.

#12

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:
pyblish-win\lib\pyblish-x\integrations\maya
pyblish-win\pythonpath

#13

Yes, probably what @mkolar said.

Otherwise, would it be possible to see your userSetup.py? It might reveal what paths it’s looking for.

#14

Yep, that was it.

Thanks @mkolar and @marcus

#15

When renaming files from validate... to _validate..., pyblish still picks them up.

Have I missed a change in the api?

#16

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?

2 Likes
#17

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.

#18

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.

#19

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.

#20

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

Versus this.

└── pyblish-magenta
    ├── extract_model.py
    ├── validate_joints.py
    ├── validate_display_layers.py
    └── conform_conceptart.py

Familiarity helps.

#21

Ahh, didn’t think to put the files into different folder. For development I can just put unwanted plugins into a temp directory.

1 Like
#22

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)
#23

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 instance.has_data['someData']

was I dreaming, or is that working?

#24

It was no dream! But it’s not implemented yet, and probably won’t be until 1.2 or even 2.0, considering it’s just semantics without any unique value.

I mentioned it here: http://forums.pyblish.com/t/api-changes
Originally from here: https://github.com/pyblish/pyblish/issues/117

1 Like