Entire path is not replicated when using create_bag_in

[axfelix]

No description provided.

[axfelix]

hey mark,

I've done a bit more work on this -- added some stubs for other functionality, and created an OSX install.app which I've tested and is working. as always, let me know if anything is unclear. if we're good, I'll update the readme to reflect that it can be installed by simply double-clicking on OSX.

[axfelix]

relatedly, I'm beginning to worry that packaging on Windows is going to be a pita -- I can't seem to get PyInstaller or py2exe to play nice with the PyGObject stuff (though it seems possible), and after some research I'm afraid we're going to end up packing like like 70M+ of Gtk libs if we expect this to be able to run standalone.

[mjordan]

Sorry not to get around to looking at this PR earlier.

I think it's time to seriously consider forking this project because 1) commit 5608d92, even though it introduces an awesome feature, added 1,645 lines of code, essentially doubling the overall size of the codebase to make installation easier on one operating system. 2) I'd rather implement what you have in the zip, ftp, and checksum stubs as extensible plugins, not independent scripts.

What do you think? I'm happy to continue work on a fork that accommodates OSX, and to give Kivy a shot as a viable replacement for GTK. But I had a specific set of goals in mind when I started this, namely, to learn to develop cross-platform GUI utility in Python that could be deployed in a variety of environments and to suit a variety of use cases. I don't see it going in that direction.

[axfelix]

I wouldn't think of 5608d92 as doubling the overall size of the codebase, since nearly all of that is literally duplicating code into the packaged .app folder; it'd probably look a lot less scary if it were actually a compiled bin rather than a packaged script (though the latter is of course much easier to create). I'd be perfectly happy to simply zip up the packaged app and store it elsewhere from Git as the "installer" link; I think that's probably more sensible anyhow. Likewise, I have no real opinion about the zip/ftp/checksum stubs as far as whether they're called as plugins or scripts; right now, they're just stubs.

I'm still seriously considering adding some case statements the way I did for the "if not Darwin" stuff and writing some PyQt code on Windows, but I think I'm probably more cynical about cross-platform libs at this point than you are ...

[axfelix]

as promised, I just ported this to Qt and it built the first try under Windows using PyInstaller (the zip came out as 12mb which isn't great but is almost certainly the best we're going to do using cross-platform frameworks on Windows). There's now code for three different GUIs in there, which I bet makes you thrilled, but hey, it works. Qt methods still need some love (haven't added success/error dialogs yet and the windows look kind of crummy), let me know how you feel about providing it.

[mjordan]

wow... got a windows binary I can try?

[axfelix]

just pull down the most recent commit, unzip createbag.zip somewhere, and run in place!

[mjordan]

Testing the .exe on my office Win7 machine. When I select a folder it just dies (I don't get a chance to create the Bag). Any way to debug what's happening? I'll test on my home machine tonight.

[axfelix]

Are you sure it's dying? Right now it's actually designed to create the bag and then automatically exit; like I said, I haven't added success/error dialogs to the Qt port yet.

[mjordan]

Hm.. on my home PC it just copied the files to the output directory and didn't create a Bag. On my office machine, it is now creating a Bag in the output directory. I won't have access to my home machine until this evening to retest.

[mjordan]

Also got this error on my home machine"

ERROR:root:[Error 5] Access is denied
Traceback (most recent call last):
  File "c:\Users\Alex\dropbox\documents\sfu\archives\createbag\build\createbag\o
ut00-PYZ.pyz\bagit", line 122, in make_bag
WindowsError: [Error 5] Access is denied
Traceback (most recent call last):
  File "<string>", line 251, in showDialog
  File "<string>", line 149, in make_bag
NameError: global name 'FolderChooserWindow' is not defined

but only on the first run. Probably a stale .pyz file?

[axfelix]

Interesting -- I'm pretty sure that file was generated by pyinstaller, so I'll need to look into the compiler settings further. Is your home machine the same one with the difficult-to-reproduce file permissions issues?

[mjordan]

Yes it is.

[axfelix]

Hm, okay. I'm tempted to think I didn't screw up dynamically linking anything, but that the tracebacks provided from a pyinstaller-built app unfortunately just refer to dev paths, and we mostly need to figure out that permissions issue so it stops dying. I've at least found a toggle to disable the stdout window, so that's good.

[axfelix]

Hey Mark,

I'm still not sure why it's dying for you on that one machine, but I've added proper success/error handling messages to the Qt/Windows version and managed to compile it to a single .exe with no scary stdout or anything. Got the filesize down by a bit too! This is probably getting to the point where it's shippable ...