Linking a module to a addon

Showing 1-9 of 9 messages
Linking a module to a addon Erik Vold 18/06/11 21:27
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/
Re: Linking a module to a addon KWierso 18/06/11 21:37
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
Re: [jetpack] Re: Linking a module to a addon Erik Vold 18/06/11 21:42
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-jetpack+unsubscribe@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

Website: http://erikvold.com/
Re: [jetpack] Re: Linking a module to a addon Erik Vold 18/06/11 22:28
Hernan mentioned a method of making symlinks within a 'packages' directory of my addon, which is working for me.

Erik
Re: [jetpack] Re: Linking a module to a addon Hernán Rodriguez Colmeiro 18/06/11 22:40
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

Re: Linking a module to a addon Mark Hammond 19/06/11 17:31
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)


Re: [jetpack] Linking a module to a addon gozala 20/06/11 02:55
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

--
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-jetpack+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

Re: [jetpack] Linking a module to a addon Mark Hammond 20/06/11 05:26
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

Re: [jetpack] Linking a module to a addon Brian Warner 20/06/11 12:16
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