655466 - document how users can make cfx activation permanent

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: Documentation, defect, P2)

Description

[Bogomil Shopov[:Bogomil]]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: 

When I execute source bin/activate the paths are visible only to current bash application. If I open a new one I must source bin/activate again.

Reproducible: Always

Comment 1

[Bogomil Shopov[:Bogomil]]

Attachment: .patch file to do that for bash

It writes in .bash_profile all PATH variables.

Comment 2

[Bogomil Shopov[:Bogomil]]

It works well on Ubuntu

Comment 3

[Dietrich Ayala (:dietrich)]

This is nice, but you don't always want the jetpack environment in your global environment. As a user, you could do this to your own .bash_profile once, and be done with it :)

Comment 4

[Bogomil Shopov[:Bogomil]]

So true, but probably most of developers aren't so familiar with Linux and will be wondering what cfx command is not found when they start another bash instance.

Isn't logic to have it and then to remove it (if you like) instead of harder way to do that?

Maybe this is a documentation issue also. Because I was trying to understand what's wrong when my bash report me cfx is not found :)

//Bogo

Comment 5

[Bogomil Shopov[:Bogomil]]

Maybe an additional parameter to bin/activate will works perfectly

bin/activate - keep the current logic
bin/activate --set[=filename] to set it in profile.

what you think?

//Bogo

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #4)
> So true, but probably most of developers aren't so familiar with Linux and
> will be wondering what cfx command is not found when they start another bash
> instance.

Presumably most of our developers aren't on Linux, they're on Windows (although they're nevertheless in a Unix-like environment if they use MozillaBuild, which we recommend).


> Isn't logic to have it and then to remove it (if you like) instead of harder
> way to do that?

Hmm, not sure.  That depends on developer expectations for changes to PATH, which are not very clear to me at this point.  What do other SDKs do?


> Maybe this is a documentation issue also. Because I was trying to understand
> what's wrong when my bash report me cfx is not found :)

I think this is the right next step: we should document what cfx activate does and explain how people can make the change permanent.  Then we can gather more info about developer behavior and possibly change the behavior in the future if it seems warranted.


Resummarizing accordingly, confirming, and moving to the Documentation component!

Comment 7

[Bogomil Shopov[:Bogomil]]

>Presumably most of our developers aren't on Linux,
Maybe in future they will be :)

I still think if we use parameters (in Comment5) AND document them will be best outcome of this bug

Thanks,
Bogo

Comment 8

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #7)
> >Presumably most of our developers aren't on Linux,
> Maybe in future they will be :)

That's a great reason to do this in the future rather than the present. :-)


> I still think if we use parameters (in Comment5) AND document them will be
> best outcome of this bug

Typically, users manage their own .bash_profile files, and the patch creates a variety of problems, including:

1. it hardcodes PATH and PYTHONPATH in .bash_profile;
2. it can result in .bash_profile defining PATH and PYTHONPATH more than once (which is confusing, especially if the file is long enough that both definitions aren't visible on the same page when reading the file);
3. it doesn't apply the changes to interactive non-login shells.

Nevertheless, I can imagine us setting these values via a machine-manageable configuration file in the future.  But .bash_profile isn't that file.

Comment 9

[Jeff Griffiths]

*bump* 

It seems like all I need to do to run cfx docs|test|run|build without first sourcing activate ( on OS X, as it happens ) is put 

<sdk-root>/bin

on my $PATH.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(automatic reprioritization of 1.0 bugs)

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 12

[Will Bamberg [:wbamberg]]

Attachment: Documenting activate, and making it permanent

I've intentionally not listed all the variables that get set by these scripts, because I don't think we intend to 'support' this yet, so it just says, "here's the general principle, and here's where you can find the variables".

While I was messing around in this file I also implemented the simple fix for bug 671811: just omit the prompts.

Comment 13

[Brian Warner [:warner :bwarner]]

Comment on attachment 571073 [details] [diff] [review]
Documenting activate, and making it permanent

Yeah, that's reasonable. There's an easier way, at least on unix-ish systems (I haven't tried on windows): just symlink the SDK's bin/cfx into your personal ~/bin directory. The 'cfx' executable is smart enough to locate itself and then set the two environment variables (CUDDLEFISH_ROOT and PYTHONPATH) relative to its location. Users who have already set up a ~/bin (and put it on their $PATH, fairly common in the unix world) should find the symlink approach easier, as it then won't affect the behavior of other python programs: just cfx.

 ln -s PATH_TO_SDK/bin/cfx ~/bin/cfx

But the text as it stands is fine to land too.

Comment 14

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Attachment: My jetpack script

FWIW, this is my jetpack script. Could be more flexible but for someone doing dev consistently against, say, a checkout of the stabilization branch.

Comment 15

[Will Bamberg [:wbamberg]]

Thanks! I added the bit about the symbolic link and landed it as:

https://github.com/mozilla/addon-sdk/commit/2d25921b54e675b7917c47da8f1f93fd74fdc252

Comment 16

[Myk Melez [:myk] [@mykmelez]]

https://github.com/mozilla/addon-sdk/commit/750d8f66d614fee5b7969777cd0a552c41d69187