# Import from global and project script library failing randomly

**URL:** <https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822>\
**Category:** Ignition\
**Created:** [July 13, 2018, 10:22pm UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822 "2018-07-13T22:22:06Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![BillS](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@BillS](https://forum.inductiveautomation.com/u/BillS)\
**Post date:** [July 13, 2018, 10:22pm UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/1 "2018-07-13T22:22:06Z")

</div>

Hello,

Every so often I get an error when importing a script module stored in the gateway global script library. The error is ImportError: No module named shared

```auto
	from shared.util.MWESLogging import getLog
	import sys

```

I have also tried to use import shared.util.MWESLogging as mwesLogging and called the method with mwesLogging.getLog because I read in one of the other posts that the “from” method of importing sometimes has issues. But I get the same error.

Usually the methods work, but sometimes it fails and I’d like to know why. I tried putting it in the project script library but then it just said it couldn’t find the “project” module instead of the “shared” module.

I have attempted to move at least this code which is used all over the place! into a custom method attached to the project’s header line window or navigation window and while that works somewhat it complains at startup of the project because those windows are not always started first.

I have complained to IA about this problem with a different project that was using mostly server side scripts called from blocks in the SFC charting, but did not get a resolution to that problem.

I’ve got one window with multiple reused sub components (templates) where I get 300-400 errors, that I switched over to a combination of

```auto
win=system.gui.getWindow("Header Line")
logger=win.getLogger(....)

```

The window getLogger method does the EXACT SAME IMPORT, and it works there!

The additional problem is that this isn’t the only method I have in the shared script libraries, it’s just the method used the most. I am having similar issues with other methods, where I’ve just copied them into the window elements as custom methods which is not really nice.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 13, 2018, 10:46pm UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/2 "2018-07-13T22:46:16Z")

</div>

Try not importing it at all. Just call `shared.util.MWESLogging.getLog()`. Due to object lifetimes in the gateway, it is unwise to ever import anything from shared.\* or project.\*. Just use the full names wherever you need them. It shouldn't be a problem in the client either, but the designer also has weirdness.

Import all you want from java. That is a pure jython operation and is effectively bulletproof. Other than the fact you can't use wildcards.

See this topic:

> [@Some Project Resources not publishing](http://forum.inductiveautomation.com/t/some-project-resources-not-publishing/16888/3):
>
> This may be a side-effect of the fact that Ignition doesn’t/can’t track the usage and retention of python code objects throughout the gateway. This means that when your script modules have interlocking dependencies, updating one script won’t impact the code objects that other scripts have imported. You may need to make a trivial change in all of your scripts and save them all together to get it to “take”. You may also need to disable then re-enable the entire project. Consider renaming the o…

---

<div class="post-metadata">

**Author:** ![BillS](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@BillS](https://forum.inductiveautomation.com/u/BillS)\
**Post date:** [July 14, 2018, 12:30am UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/3 "2018-07-14T00:30:25Z")

</div>

I have tried that also with mixed success… I found another post indicating that there may be problems with names that start with upper case letters. So I’m attempting to move to project script library with all lower case names to see if things become a bit more stable.

Thank you for your quick reply!

---

<div class="post-metadata">

**Author:** ![BillS](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@BillS](https://forum.inductiveautomation.com/u/BillS)\
**Post date:** [July 18, 2018, 1:26am UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/4 "2018-07-18T01:26:37Z")

</div>

Ok, I switched ALL my custom methods and event handlers to do something like this:

```auto
self = event.source
logger = project.util.logging.getLog(method="propertyChange", lib=self.LibraryName, src=self.SourceName)

```

and

```auto
	logger = project.util.logging.getLog(lib=self.LibraryName, src=self.SourceName, useStack=True)
	project.util.logging.logMethodStartup ( logger ) 	

```

and now SOMETIMES I’m getting the following error

```auto
NameError: global name 'project' is not defined

```

This is very frustrating.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 18, 2018, 3:41am UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/5 "2018-07-18T03:41:08Z")

</div>

Some events (I don’t recall which) use a legacy python scope where system, shared, and project names exist only at the top level, and have to be imported individually in any nested functions. The best way to deal with this is to avoid defining functions and classes in event scripts themselves – always do that in script modules where modern scoping is reliable.

---

<div class="post-metadata">

**Author:** ![BillS](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@BillS](https://forum.inductiveautomation.com/u/BillS)\
**Post date:** [July 18, 2018, 6:48pm UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/6 "2018-07-18T18:48:47Z")

</div>

I’m not entirely sure what you are talking about here. Can you provide examples of what you mean?

I’ve seen this error both in the custom methods and at the event handler level. And it works sometimes and other times it won’t.

---

<div class="post-metadata">

**Author:** ![systemparadox](https://avatars.discourse-cdn.com/v4/letter/s/b5e925/32.png) [@systemparadox](https://forum.inductiveautomation.com/u/systemparadox)\
**Post date:** [July 31, 2018, 7:26am UTC](https://forum.inductiveautomation.com/t/import-from-global-and-project-script-library-failing-randomly/18822/7 "2018-07-31T07:26:39Z")

</div>

Phil is referring to the fact that in “legacy scoping”, the following happens:

```auto
# event, project, shared, system are available here
def foo():
    # but they are not available here unless you import them

```

In “standard scoping” this works correctly. You should always use standard scoping where available - there is no reason to use legacy scoping. Unfortunately event scripts and tag change scripts use legacy scoping and there is no option to change it. To be honest, I don’t understand why they’ve even made this an option - they should have just changed it everywhere. I cannot think of any case where this would break backwards compatibility.

However, you appear to be running into a long-standing bug with custom functions that keeps tripping me up. A custom function called from visionWindowOpened (even indirectly or via invokeLater) will get an uninitialised reference to project/shared/system, and will be unable to use them. There may also be other cases where this does not work properly, but I’m not sure of the details.