Output File Name does not default to the .catalog file name

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Create a catalog file that does not have "Output File Name" defined within 
itself or any included catalogs.
2. Run instadmg with this catalog.

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

According to instaUp2Date.py, line 447 will cause the name of the output file 
to default to the name portion of the catalog filename when there isn't an 
"Output File Name:" line in any catalog. nstead this error is returned:

    Setting up InstaDMG folders
Traceback (most recent call last):
  File "/Users/cda/svn/instadmg/AddOns/InstaUp2Date/instaUp2Date.py", line 716, in <module>
    main()
  File "/Users/cda/svn/instadmg/AddOns/InstaUp2Date/instaUp2Date.py", line 705, in main
    thisController.runInstaDMG(scratchFolder=options.instadmgScratchFolder, outputFolder=options.instadmgOutputFolder)
  File "/Users/cda/svn/instadmg/AddOns/InstaUp2Date/instaUp2Date.py", line 447, in runInstaDMG
    self.outputFilePath = os.path.join(commonConfiguration.standardOutputFolder, os.path.splitext(os.path.basename(self.catalogFilePath)))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py", line 65, in join
    if b.startswith('/'):
AttributeError: 'tuple' object has no attribute 'startswith'

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

r413

What OS are you running on (booted from)?

OS X 10.6.6

What OS are you installing?

OS X 10.6

Please provide any additional information below.

The error is that os.path.splitext returns a tuple, but we only want a single 
string. This can be fixed with a small change. The line below should replace 
that on 447:

            self.outputFilePath = os.path.join(commonConfiguration.standardOutputFolder, os.path.splitext(os.path.basename(self.catalogFilePath))[0])

With this change it becomes easier to nest multiple catalogs at arbitrary 
levels, assuming one is okay with always having the output file name the same 
as the catalog file.

Original issue reported on code.google.com by t...@synthist.net on 23 Jan 2011 at 10:59

[GoogleCodeExporter]

looking in to this behavior for possible ways this may be tripping up people 
generating multiple images sequentially, but considering this an enhancement. 
Since the previous devs hadn't accounted for this functionality, I will 
investigate myself and encourage anyone available to please assist in producing 
test(s) to ensure the adding of this functionality is covered in unittest.

Original comment by allister...@gtempaccount.com on 28 Jan 2011 at 1:09

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

It doesn't directly have anything to do with generating multiple images 
sequentially. It only concerns the functionality of naming the output filename 
in case it isn't defined in any catalog used in a build. The simplest example 
would be that I have a single catalog file with no other included catalogs, but 
without an Output File Name: specified. If I run instaUp2Date on this single 
catalog file, it will fail with AttributeError.

The previous devs did account for this functionality. This is not an 
enhancement, it is a fix.

If you look at the code where I'm pointing to, there is a comment saying 
exactly what the intended functionality is, and there is an error in the 
function call. You see a *working* example of os.path.splitext used within 
os.path.join in the very next line. It's very simple oversight in the code.

Generating multiple images in one command was clearly of importance to Karl, if 
you look at this issue:

http://code.google.com/p/instadmg/issues/detail?id=40&can=1

But he was likely always going by naming specifying his output filenames in the 
.catalog files. This methodology doesn't work for me because I want to build at 
multiple stages within one chain, and instaUp2Date's behaviour of only 
retaining the innermost-nested Output File Name: argument when they are 
specified prevents me from doing this. Whether that is intended behaviour or 
not is outside the scope of this issue.

Original comment by t...@synthist.net on 28 Jan 2011 at 3:37

[GoogleCodeExporter]

You are absolutely correct.  I had not looked at the comment and apologize for 
the oversight.  I will get on this as soon as possible and have changed the 
type accordingly.  Thank you for your explanation and patience with me.

Original comment by allister...@gtempaccount.com on 28 Jan 2011 at 4:03

• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

This change has been checked in and no complications have been reported. 

Original comment by allister...@gtempaccount.com on 15 Feb 2011 at 1:50

• Changed state: Fixed