I have both 123.py and 456.py under scripts/. In H21 both run, but in H22 only 123.py runs? Is something changed? The doc (https://www.sidefx.com/docs/houdini/hom/locations.html) still says 456.py is a thing.

I have had the same issue, did you make a bug report? I'm thinking I'll make one.

I heard from SideFX Support that this problem was solved in Houdini22.0.386.

I had the same issue, turned out the 456.py of the Labs was taking over.

Check if there is a file in here (for Windows), if so rename it and maybe copy its contents to your own file:

C:\Program Files\Side Effects Software\sidefx_packages\SideFXLabs22.0\scripts/456.py

akihito20x0
I heard from SideFX Support that this problem was solved in Houdini22.0.386.

No it doesn't

jim707jim707jim

akihito20x0
I heard from SideFX Support that this problem was solved in Houdini22.0.386.

No it doesn't

Oh. I reported a bug and received so from SideFX Support.
But I haven't tested it yet because I don't use daily builds.

If so, we should report the bug again.

It also doesn't work with 456.py in Houdini 22.0.429.
So I made a bug report again and it was submitted.

I could figure it out.

If you have a package that has 456.py, your local 456.py is ignored.
And the latest production build of SideFX Labs have 456.py.

If you update it to the latest daily build that don't have 456.py, it works well with your 456.py.

akihito20x0
I could figure it out.
If you have a package that has 456.py, your local 456.py is ignored.

Can we control the order of loaded packages?

ajz3d

akihito20x0
I could figure it out.
If you have a package that has 456.py, your local 456.py is ignored.

Can we control the order of loaded packages?

What do you mean?
Do you have two or more packages that have 456.py?

akihito20x0
Do you have two or more packages that have 456.py?

No, but I was wondering about a scenario where two packages had the same file (in the same path of the package's directory structure), like 456.pyfor example. In other words - which package would overwrite such file belonging to another package. I checked the docs, and it turns out that by default, packages are processed in alphabetical order, but we can alter this order by manually inserting process_orderkeyword in JSON files of each package:

https://www.sidefx.com/docs/houdini/ref/plugins.html#package_order [www.sidefx.com]

So it's good to know that we have some means of resolving this kind of conflicts, which are silent, because we're not notified about which package overwrites the content from another package when it's loaded.

ajz3d

akihito20x0
Do you have two or more packages that have 456.py?

No, but I was wondering about a scenario where two packages had the same file (in the same path of the package's directory structure), like 456.pyfor example. In other words - which package would overwrite such file belonging to another package. I checked the docs, and it turns out that by default packages are processed in alphabetical order, but we can alter this order by manually inserting process_orderkeyword in JSON files of each package:

https://www.sidefx.com/docs/houdini/ref/plugins.html#package_order [www.sidefx.com]

So it's good to know that we have some means of resolving this kind of conflicts, which are silent, because we're not notified about which package overwrites the content from another package when it's loaded.

I think the user 456.py is overwritten by packages, then packages usually should be designed not to have 456.py.
Houdini SideFX Labs 22 initially have 456.py. It is the bug. It hasn't had it before. And doesn't have it now.

The bug is not that Labs have a 456.pybut that Houdini don't execute all the 456.py. Each package should be able to have those files otherwise it would be a management nightmare.

This code doesn't check for recursion but it should check for all 456 files.

I think this still should be treated as a bug. Why should a package's 456.py prevent the other one's from running? It doesn't make a lot of sense. They should just all run one by one. Has any reported this to SideFX?

Regnareb
The bug is not that Labs have a 456.pybut that Houdini don't execute all the 456.py. Each package should be able to have those files otherwise it would be a management nightmare.

This code doesn't check for recursion but it should check for all 456 files.

import os
for path in hou.houdiniPath():
    if (os.path.exists(path + '/python3.11libs/456.py')):
        exec(open(path + '/python3.11libs/456.py').read())
    if (os.path.exists(path + '/python3.13libs/456.py')):
        exec(open(path + '/python3.13libs/456.py').read())
    if (os.path.exists(path + '/456.py')):
        exec(open(path + '/456.py').read())

But previous versions or older versions are the same.
It's the specification.

Where in the specification does it says that?
There are bugs that were there 10 years ago, they are still bugs despite their lifespan.

If only one 456.py can execute, it means any package overrides any other package functionality. That would be crazy.

Regnareb
Where in the specification does it says that?
There are bugs that were there 10 years ago, they are still bugs despite their lifespan.

If only one 456.py can execute, it means any package overrides any other package functionality. That would be crazy.

Regnareb
Where in the specification does it says that?
There are bugs that were there 10 years ago, they are still bugs despite their lifespan.

If only one 456.py can execute, it means any package overrides any other package functionality. That would be crazy.

Regnareb
Where in the specification does it says that?
There are bugs that were there 10 years ago, they are still bugs despite their lifespan.

If only one 456.py can execute, it means any package overrides any other package functionality. That would be crazy.

SideFX guys said.
Anyway I don’t think they leave a bug for 10years.
It’s normal for me.

No way this is the intended behavior. And if it were, that'd be a really bad design.

kodoragon
No way this is the intended behavior. And if it were, that'd be a really bad design.

You think so?

Personally I don't think packages should handle 456.py.
If it's the case of 123.py, it's understandable for me though.

456.py is a startup script that runs when a scene is created or loaded.
I think it's for a designer or a machine. It's not for a system(including packages).

I also have some complaints about that.
For example, then why does it ignore my local 456.py or something like that.

But it works just like the previous version now. It works for me.

Anyway you can make a feature request.