Opened 7 years ago

Closed 6 years ago

#2892 closed defect (fixed)

Refactor bundlebuilder

Reported by: marco Owned by: marco
Priority: normal Milestone: Opportunity
Component: sugar Version:
Keywords: review? Cc: homunq, marco, tomeu
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

It was initally supposed to be a very simple script to package .xo but then we had to add several functionalities, included localization. The interface should be mostly fine but the internals needs to be reorganized and cleaned up.

We might consider adding a way to package external code/data or at least to make it easy to plugin code to do so (integration/extension of setuptools?).

Attachments (4)

bundlebuilder.py (15.2 KB) - added by homunq 7 years ago.
bundlebuilder.2.py (15.2 KB) - added by homunq 7 years ago.
bundlebuilder.diff (24.4 KB) - added by homunq 7 years ago.
bundlebuilder.2.diff (24.4 KB) - added by homunq 7 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by homunq

  • Owner changed from dcbw to homunq

I need to do this for develop. Assigning myself the bug. I will NOT try to make it look beautiful internally, I will only do what is necessary to add the functions I need (call it from another working directory, send the output to a third directory, not screw up what works already).

Changed 7 years ago by homunq

Changed 7 years ago by homunq

comment:2 Changed 7 years ago by homunq

  • Cc homunq added
  • Resolution set to fixed
  • Status changed from new to closed

The two attachments are identical, sorry, trac growing pains.

The first step in making this callable from other code is to remove the dependency on the current working directory. I did this by moving all the functions into a new class Bundlebuilder, which has its directory as an instance member variable; making a default instance bundlebuilder; and exporting all the methods from bundlebuilder into the module globals.

There is still plenty of room for improvement in various ways. Nonetheless, I am resolving this as "fixed" so that somebody will notice and move this change into sugar. If this is the wrong process, I'm sorry.

comment:3 Changed 7 years ago by homunq

  • Resolution fixed deleted
  • Status changed from closed to reopened

aak, what is the status for "fix proposed"? I will figure this out.

comment:4 Changed 7 years ago by homunq

  • Cc marco tomeu added
  • Keywords review? added
  • Resolution set to fixed
  • Status changed from reopened to closed

comment:5 Changed 7 years ago by homunq

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:6 Changed 7 years ago by homunq

Does anybody know why bundlebuilder passes around the name of the manifest file ('MANIFEST') as a variable? Is that expected to ever change, or would it be better as a 'constant' global variable (which could be changed by poking into the module anyway)?

I'm reluctant to change the call signatures on a file others use, but it seems really useless - it is defaulted by all the public functions and then passed intact to the private ones. So I'm tempted to make it a global.

Changed 7 years ago by homunq

Changed 7 years ago by homunq

comment:7 Changed 7 years ago by homunq

OK, here is the patch. It is also in my git at http://dev.laptop.org/git?p=users/homunq/sugar-toolkit;a=commit;h=bb

comment:8 Changed 7 years ago by homunq

  • Owner changed from homunq to marco
  • Status changed from reopened to new

Marco, you said you were doing further work on this. Am reassigning bug to you. Feel free to send it back if you want me to consider it further (everything beyond cmd_dist and extract_bundle is still pretty messy, more like a private shell script than an OS component).

comment:9 Changed 6 years ago by marco

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.