Closed Bug 655466 Opened 11 years ago Closed 11 years ago

document how users can make cfx activation permanent

Categories

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

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Bogomil, Assigned: wbamberg)

Details

(Whiteboard: [cherry-pick-1.3])

Attachments

(2 files, 1 obsolete file)

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
Attached patch .patch file to do that for bash (obsolete) — Splinter Review
It writes in .bash_profile all PATH variables.
It works well on Ubuntu
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 :)
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
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
(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!
Status: UNCONFIRMED → NEW
Component: General → Documentation
Ever confirmed: true
OS: Linux → All
QA Contact: general → documentation
Hardware: x86 → All
Summary: Add paths permanently to .bash_profile under Gnu/Linux → document how users can make cfx activation permanent
>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
(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.
Priority: -- → P3
Target Milestone: --- → 1.0
*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.
(automatic reprioritization of 1.0 bugs)
Priority: P3 → P2
Target Milestone: 1.0 → 1.1
(Pushing all open bugs to the --- milestone for the new triage system)
Target Milestone: 1.1 → ---
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.
Assignee: nobody → wbamberg
Attachment #530824 - Attachment is obsolete: true
Attachment #571073 - Flags: review?(warner-bugzilla)
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.
Attachment #571073 - Flags: review?(warner-bugzilla) → review+
Attached file 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.
Thanks! I added the bit about the symbolic link and landed it as:

https://github.com/mozilla/addon-sdk/commit/2d25921b54e675b7917c47da8f1f93fd74fdc252
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.