Linking a module to a addon

[Erik Vold]

Hello,

I've made a module that I want to use in a addon, both projects are separate git repos which I keep in a folder called /github/. Now I want to cfx xpi to find the module when I build the addon, and I've been trying a lot of different things without success; what is the best way to do this?

Thanks,

Erik

--
Erik Vergobbi Vold

Email: erik...@gmail.com
Website: http://erikvold.com/

Github: http://github.com/erikvold
Identi.ca: http://identi.ca/erikvold
LinkedIn: http://www.linkedin.com/in/erikvold

[KWierso]

I think you could use the "--extra-packages" flag for cfx, as
explained here: https://jetpack.mozillalabs.com/sdk/1.0b5/docs/dev-guide/addon-development/cfx-tool.html

Don't quote me on that, though.

On Jun 18, 11:27 pm, Erik Vold <erikvv...@gmail.com> wrote:
> Hello,
>
> I've made a module that I want to use in a addon, both projects are separate
> git repos which I keep in a folder called /github/. Now I want to cfx xpi to
> find the module when I build the addon, and I've been trying a lot of
> different things without success; what is the best way to do this?
>
> Thanks,
>
> Erik
>
> --
> Erik Vergobbi Vold
>

> Email: erikvv...@gmail.com

[Erik Vold]

That page says --extra-packages is for:

"Extra packages to include, specified as a comma-separated list of package names. Defaults to addon-kit."

I don't see how it's supposed to find my package if I don't use a path here, but no matter what I use I get a "AttributeError: 'list' object has no attribute 'startswith'" error.

Erik

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

--
Erik Vergobbi Vold

Email: erik...@gmail.com

[Erik Vold]

Hernan mentioned a method of making symlinks within a 'packages' directory of my addon, which is working for me.

Erik

[Hernan Rodriguez Colmeiro]

On Sat, Jun 18, 2011 at 22:28, Erik Vold <erik...@gmail.com> wrote:
> Hernan mentioned a method of making symlinks within a 'packages' directory
> of my addon, which is working for me.

The solution that almost always work for me is the following:

1) I have a symlink in the packages dir of my addon:
myAddon/packages/myOtherPackage -> ~/Projects/myOtherPackage

2) In the packages.json, I add the following property:
dependencies: "api-utils,addon-kit,myOtherPackage"

And that does the job.

Hernán

[Mark Hammond]

On Jun 19, 2:27 pm, Erik Vold <erikvv...@gmail.com> wrote:
> Hello,
>
> I've made a module that I want to use in a addon, both projects are separate
> git repos which I keep in a folder called /github/. Now I want to cfx xpi to
> find the module when I build the addon, and I've been trying a lot of
> different things without success; what is the best way to do this?

I've struck the exact same problem. What does work (but with caveats)
is to use something like:

% cfx --package-path=/path/to/external/addon/PARENT

and to list the dependencies as already discussed. However, this
isn't great - as above, you must point at the *parent* directory of
the "external" addon, and that parent must only have children which
have a package.json file - ie, that parent directory must be laid out
like the addon-sdk/packages directory - any number of child
directories but each must have package.json.

For example, let's assume you have a directory /path/to/external/addon/
jetpack where your package.json lives. You could then use the
cmdline:

% cfx --package-path=/path/to/external/addon

The jetpack SDK will enumerate all child directories of the specified
patch (eg, 'jetpack') and look for a package.json there. However,
this is problematic in my use-case - the parent directory of my
external addon (ie, /path/to/external/addon) holds 'jetpack' but also
other unrelated child directories, and therefore they don't have a
package.json (ie, only the 'jetpack' child dir has package.json) - and
therefore I get an error about the missing package.json in these
unrelated child directories.

I worked up a patch so that if the directory pointed at by --package-
path has a package.json, then the child directories aren't searched -
the specified directory is used directly. With this patch, you simply
say:

% cfx --package-path=/path/to/external/addon/jetpack

and all is good.

I've included the patch below and while I think I should attach it to
a bug, I figured I'd look for some feedback here first (ie, is it
really a bug? If so, is my approach optimal, or is some other
approach better?)

Patch is below...

Cheers,

Mark

index 2b42adf..3dfc2ae 100644
--- a/python-lib/cuddlefish/packaging.py
+++ b/python-lib/cuddlefish/packaging.py
@@ -230,11 +230,14 @@ def build_config(root_dir, target_cfg,
packagepath=[]):

while dirs_to_scan:
packages_dir = dirs_to_scan.pop()
- package_paths = [os.path.join(packages_dir, dirname)
- for dirname in os.listdir(packages_dir)
- if not dirname.startswith('.')]
- package_paths = [dirname for dirname in package_paths
- if os.path.isdir(dirname)]
+ if os.path.exists(os.path.join(packages_dir,
"package.json")):
+ package_paths = [packages_dir]
+ else:
+ package_paths = [os.path.join(packages_dir, dirname)
+ for dirname in os.listdir(packages_dir)
+ if not dirname.startswith('.')]
+ package_paths = [dirname for dirname in package_paths
+ if os.path.isdir(dirname)]

for path in package_paths:
pkgconfig = get_config_in_dir(path)

[Irakli Gozalishvili]

Option 1:

Keep all the jetpack libs / packages in the packages folder of addon-sdk or symlink them there and specify dependencies in the package.json

Option 2:

git submodules

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

[Mark Hammond]

On 20/06/2011 7:55 PM, Irakli Gozalishvili wrote:
> Option 1:
>
> Keep all the jetpack libs / packages in the packages folder of addon-sdk
> or symlink them there and specify dependencies in the package.json
>
> Option 2:
>
> git submodules

IMO, they are work-arounds but not particularly friendly ones. The SDK
really should be able to stand-alone and not require a build process to
locate and modify it.

I assumed --package-path exists in an attempt to support packages
external to the SDK - or have I missed the point of that option?

Mark

[Brian Warner]

On 6/20/11 5:26 AM, Mark Hammond wrote:

> On 20/06/2011 7:55 PM, Irakli Gozalishvili wrote:
>> Option 1:

>> Option 2:

>
> IMO, they are work-arounds but not particularly friendly ones. The SDK
> really should be able to stand-alone and not require a build process to
> locate and modify it.
>
> I assumed --package-path exists in an attempt to support packages
> external to the SDK - or have I missed the point of that option?

Yeah, --package-path is intended to do just that. I implemented it to
point to a directory *containing* packages, rather than pointing
directly at the extra packages, because 1: it was slightly easier, and
2: that's how it tends to work in other languages/environments: e.g.
$PYTHONPATH in Python, $PERL5LIB in Perl, and -I/-L/$LD_LIBRARY_PATH in
gcc. A consequence is that you have to maintain a library directory with
just packages in it.

Your --package-path-points-to-a-package patch (say that 5 times fast!)
is intriguing.. I gotta think about that one. There are two things that
it might interact with. One is that, at least in theory, packages can
contain subpackages. The other is that --package-path is actually a
comman-separated list of directories, so we should make sure it can
handle that (iterate through each one, look for a package.json, either
add the package directly or scan its subdirectories for packages).

Definitely file a bug on that, and copy me (:warner), so I don't forget
about it.

cheers,
-Brian