InstaUp2Date relative module imports fail on Python 2.6.6 and up

GoogleCodeExporter commented 8 years ago

What steps will reproduce the problem?
1. Run instaUp2Date.py with python 2.6.6 or later.

What is the expected output? What do you see instead?

Traceback, with from .Resources.pathHelpers import normalizePath failing to 
find pathHelpers.

What version of InstaDMG are you running? What revision number (this should
be the second line of your package log)?

svn 419

What OS are you running on (booted from)?

10.6.7

What OS are you installing?

10.6.7

Please provide any additional information below.

InstaUp2Date relies on behavior that was fixed in Python 2.6.6:

  http://bugs.python.org/issue7902

Patch attempting to fix the relative imports attached. I've verified that our 
10.6_vanilla + iLife11 workflow on 10.6.7 and Python 2.6.1 still runs. It 
appears to fix the problem with running on Python 2.6.6 on 10.7, but since 
there's no 10.7_vanilla catalog I've only done limited testing. I don't have 
any 10.5 machines to test on.

Original issue reported on code.google.com by MagerV...@gmail.com on 21 Jun 2011 at 11:34

Attachments:

instadmg-relimport.patch

GoogleCodeExporter commented 8 years ago

Will test on 10.5 ASAP and report back.  Will also run test suite against 
patched version ASAP.  Thanks, as always, Allister

Original comment by allister...@gtempaccount.com on 21 Jun 2011 at 12:47

Changed state: Accepted
Added labels: Priority-High
Removed labels: Priority-Medium

GoogleCodeExporter commented 8 years ago

Resources/runAllTests.py doesn't run, due to the relative imports trying to go 
up one level too far, but if you place a small test program one level up (next 
to instaUp2Date.py):

#!/usr/bin/python

import os
import unittest

from Resources.cacheController_test import *
from Resources.checksum_test import *
from Resources.commonConfiguration_test import *
from Resources.displayTools_test import *
from Resources.findInstallerDisc_test import *
from Resources.installerPackage_test import *
from Resources.macOSXVersionParser_test import *
from Resources.managedSubprocess_test import *
from Resources.pathHelpers_test import *
from Resources.tempFolderManager_test import *
from Resources.testingHelpers_test import *
from Resources.volumeManager_test import *
from Resources.workItem_test import *

if __name__ == '__main__':
    unittest.main()

all tests run and only three fail:

edu1410:InstaUp2Date pelle$ ./runTests.py 
.........EE.......................................E.......
======================================================================
ERROR: test_codePath (Resources.findInstallerDisc_test.findInstallerDiscTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc_test.py", line 35, in test_codePath
    allowedBuildsResults = findInstallerDisc(allowedBuilds=buildsInfo)
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py", line 201, in findInstallerDisc
    raise commonExceptions.FileNotFoundException('Unable to find OS Installer disc in any provided folder: %s%s' % (str(searchItems), folderString))
FileNotFoundException: Unable to find OS Installer disc in any provided folder: 
['/Users/pelle/instadmg/InstallerFiles/InstallerDiscs', 
'/Users/pelle/instadmg/InstallerFiles/BaseOS'] (['.svn'], ['.svn'])

======================================================================
ERROR: test_commandLine (Resources.findInstallerDisc_test.findInstallerDiscTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc_test.py", line 59, in test_commandLine
    process = managedSubprocess.managedSubprocess([pathToCommandLine, '--allowed-builds', ", ".join(buildsInfo), '--supress-return'])
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/managedSubprocess.py", line 45, in __init__
    raise RuntimeError(errorString)
RuntimeError: The process 
"/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py 
--allowed-builds 10A432, 10B504, 10C540, 10D573, 10D575, 10F569 
--supress-return" failed with error: 1
Stderr: Traceback (most recent call last):
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py", line 9, in <module>
    from container              import container
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/container.py", line 3, in <module>
    from containerTypes     import *
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/containerTypes/bundle.py", line 5, in <module>
    import file
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/containerTypes/file.py", line 5, in <module>
    from containerBase      import containerBase
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/containerTypes/containerBase.py", line 7, in <module>
    from ..pathHelpers                  import normalizePath
ValueError: Attempted relative import beyond toplevel package

======================================================================
ERROR: test_getVolumeInfo_Applications 
(Resources.volumeManager_test.volumeManagerTests)
Test that using getVolumeInfo on an item inside of a volume returns the 
volume's info
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/volumeManager_test.py", line 49, in test_getVolumeInfo_Applications
    applicationsResult = volumeManager.getVolumeInfo('/Applications')
  File "/Users/pelle/instadmg/AddOns/InstaUp2Date/Resources/volumeManager.py", line 51, in getVolumeInfo
    raise ValueError('The input to getVolumeInfo does not look like it was valid: ' + str(identifier) + "\nError:\n" + str(error))
ValueError: The input to getVolumeInfo does not look like it was valid: 
/Applications
Error:
The process "/usr/sbin/diskutil info -plist /Applications" failed with error: 1
Stdout: Could not find disk: /Applications

----------------------------------------------------------------------
Ran 58 tests in 15.566s

FAILED (errors=3)

Error 1 can probably be ignored (I don't have InstaDMG properly set up here), 
and error 3 is a different issue (I'll file another bug). Error 2 though is 
because findInstallerDisc.py is run directly, and the relative import tries to 
go up too far again. I'll keep digging and see if the test needs to be 
adjusted, or if it's a real issue.

Original comment by MagerV...@gmail.com on 21 Jun 2011 at 4:54

GoogleCodeExporter commented 8 years ago

Allister, did you get a chance to test it on 10.5? And Karl, any insight to 
share on the test?

Original comment by MagerV...@gmail.com on 2 Jul 2011 at 8:41

GoogleCodeExporter commented 8 years ago

Hey Per,
I cannot get 10.7 to run instaup2date, it fails to find the installer disk(old 
and new InstallESD naming).  I also just think moving runalltests.py into the 
same directory as instaup2date.py would simplify fixing the relative import 
issues, which I have done.  I have checked and tests run on all three 
OS's(10.5, 10.6 and 7), with two of the same failures on 10.7 you posted 
above(I was able to fix the test_codePath part of findInstallerDisc). 

Karl, why were we testing for wether diskutil would return info from the 
Applications directory?  Just like python's relative import bug in previous 
version that shipped with the OS, it seems like unintentional behavior.  I'm 
slowing pushing my python skills uphill, but I would rather cover all cases 
with one better practice rather than write conditionals.

Original comment by allister...@gtempaccount.com on 1 Aug 2011 at 6:50

Changed state: Started

GoogleCodeExporter commented 8 years ago

To find the installer disk, there's a couple extra places we need to add the 
updated Packages path for the Lion installer volume:
- Resources/volumeManager.py
- Resources/containerTypes/volume.py

Attaching a patch for these. It should be patched against r419 *after* Per's 
patch is applied. I didn't bother trying to re-base these to r425, the changes 
are very simple and could quickly be done manually when they're finally ready 
for trunk.

To facilitate quicker testing, the patch also creates a 10.7_vanilla.catalog 
with the appropriate build number, and adds the Java + QuickTime 7 packages 
from Apple.

The QuickTime 7 should eventually be left out of vanilla because it pulls from 
their sucatalog as opposed to the official Support Downloads page, but I left 
it there so that it might be documented elsewhere or useful for someone. For my 
organization, it's analogous to having QT7 as an InstallerChoices in 10.6, so 
we will certainly have it as part of our base image.

Original comment by t...@synthist.net on 8 Aug 2011 at 6:57

Attachments:

instadmg-instaUp2Date_lion_installer_paths.patch

GoogleCodeExporter commented 8 years ago

I should correct myself. Since Per's changes have been incorporated into r425, 
my patch can be built against that, rather than r419.

The 10.7_vanilla catalog I posted in the patch is also missing the ARD 3.5.1 
client update and iTunes 10.4 updates, but these can be pulled from the 10.6 
catalog.

Original comment by t...@synthist.net on 9 Aug 2011 at 3:44

GoogleCodeExporter commented 8 years ago

this obviously was lingering for a bit, closed.

Original comment by a...@aru-b.com on 6 Oct 2012 at 2:35

Changed state: Fixed

ddodds / instadmg

InstaUp2Date relative module imports fail on Python 2.6.6 and up #92