Add portable version of Atom

[bnjmnt4n]

I don’t really stick to one computer to program, and some computers don’t have editors. Currently I use Sublime Text portable, but it would be great if there was a portable version of Atom.

[batjko]

I haven't tried it yet, but isn't the released zip file a portable version?

[bnjmnt4n]

Nope, it stores settings on the current computer itself, so once you switch computers all your settings are gone.

[benogle]

Can you link us to some documentation on what makes an app portable? Is that the only difference?

[bnjmnt4n]

I’m not too sure about any docs, but as far as I know, all settings / installed themes and packages should be stored in the Atom folder instead of the computer itself, so it still works when running from a thumbdrive.

[kevinsawicki]

Yeah, we could definitely do this, tweaking Atom to store things locally in a .atom folder instead of the current location should be relatively straightforward.

[batjko]

Yes that's pretty much the criterium for an app to be "portable":
All settings and executables must be contained under a parent folder, and nothing is to be 'installed' to - or required from - anywhere else in the system.

As @D10 says, the purpose being that you could run it from a thumb drive without leaving a trace on the system.

[schodge]

Can you add the link to the zip to the README.md ? Until I found this post I thought a choclately install was my only option.

[kevinsawicki]

@schodge Sure thing, added in commit 262ba6b

[schodge]

Thanks!

Kevin Sawicki mailto:notifications@github.com
Sunday, July 13, 2014 5:57 PM

@schodge https://github.com/schodge Sure thing, added in commit
262ba6b
262ba6b

—
Reply to this email directly or view it on GitHub
#2939 (comment).

[MiniFlames]

would it be possible to allow the user to set a custom location for the .atom folder? so I could [for example] move it to another drive or to my dropbox/onedrive/cloud storage of choice folder

[batjko]

@MiniFlames I was thinking of that as well. Especially since re-installing packages, themes and personal settings on several different machines (home desktop, private laptop, work laptop etc) would be quite the breeze if one could just move that folder to dropbox or google drive etc, and have a setting in the settings-view to point .atom to that location.

[joefitzgerald]

Allowing the location of the .atom folder to be configurable presents a configuration catch-22. The config is stored in the .atom folder, so Atom needs to be able to find it (but how can it find it without reading the config).

The obvious solution would be to permit this location to be overridden via environment variable... would that work?

[schodge]

@joefitzgerald "The obvious solution would be to permit this location to be overridden via environment variable..."

I think it'd be easier to have a configuration file in the root atom directory, one line only, to point to .atom's location, and to assume the default if the file doesn't exist.

However, I also think that so long as .atom is located under the main atom folder by default in the portable version that the simplest solution would be for the user to symlink to it. No extra config, no environment variables to worry about, and transparent to the program.

[MiniFlames]

The problem with symlinks is windows, whilst it's doable it's a complete 'mare to set them up on windows [compared to osx/linux].

I like the sound of @schodge 's first suggestion though

Ultimately though if having user-definable .atom location is too much grief to implement so be it.

[joefitzgerald]

Yes, the one advantage of an environment variable is all platforms have an environment, and interaction with it is fairly consistent.

A single internal config file (.atom.location?) with the location of the .atom folder would also work, but would be awkward on OS X, where you'd be modifying the package contents if you changed it. Perhaps - in order of precedence - the following might apply:

• Check the environment for a variable, which – if set – is used
• Check the atom folder for the presence of an .atom.location file (which would not be present by default), and use the location specified in it
• Use the default location for the platform

[joefitzgerald]

As an aside, supporting an environment variable would allow very easy maintenance of multiple configuration profiles:

$ ATOM_CONFIG_LOCATION=~/myawesomeconfigfolder atom .
$ ATOM_CONFIG_LOCATION=~/mysuperawesomeconfigfolder atom .

[schodge]

@MiniFlames @joefitzgerald A symbolic link on Win should be mklink .\atom\ <desired_path>, possibly with a /J switch. If you have ownership of both source and destination I'm not sure if an elevated prompt is required.

OTOH, environment variables generally require using a GUI to permanently change. (Or, at least PATH does). At least in my experience, environment variables are a bigger pain on Win than symlinks.

[joefitzgerald]

http://technet.microsoft.com/en-us/library/cc755104.aspx << setx sets environment variables permanently from the command line.

[schodge]

@joefitzgerald Please file my last post under "totally full of malodorous substance." Somehow I never stumbled across setx before, only set.

[tlgreg]

I think there should be a solution (possibly additionally to the environment variable) which doesn't need any modification to the host system, like the .atom.location file or an argument like --local-config or something.

[joefitzgerald]

That's what I'm suggesting - multiple options with order of precedence. I like the option for a flag also.

[schodge]

@joefitzgerald Agreed.

[Ajtak]

I'm too for portable version.

[bnjmnt4n]

Any idea when this can be done and released?

[sketchpunk]

http://wiki.audacityteam.org/wiki/Portable_Audacity Audacity's way of making an app portable seems like a simple and straight forward way of doing it. If the .atom folder exists at the root of the app folder, use that else use the system. Depending on how the app knows where the .atom folder is to begin with, it might be an easy add on without needing any special setting screen or anything.

[zackp30]

👍 This would be great!

[ghost]

Here is a quick fix:

    Atom.getConfigDirPath = function() {
      if (fs.existsSync(process.cwd() + "/.atom")) {
        return this.configDirPath = process.cwd() + "/.atom";
      }
      return this.configDirPath != null ? this.configDirPath : this.configDirPath = fs.absolute('~/.atom');
    };

In: Atom/resources/app/src/atom.js, line 95

[sketchpunk]

Awesome, i had a feeling that's all that needed to be changed. Beat me to it :)

[batjko]

@paulcbetts I think what people still wait for is a Portable Mode™ that comes out of the box. For example the zipped release version could be made to be fully self-contained (not relying on env vars etc)

They don't want to have to set any environment variables, use command line switches or whatnot.

[dead-claudia]

@batjko That may very well be the best way IMHO.

[anaisbetts]

@batjko I think we're violently agreeing here, basically we use process.execPath to detect whether we're installed, then if we're not installed, we operate in Portable Mode.

[proimage]

The problem with that approach is if Atom is "installed" in portable mode in Dropbox or a USB drive, and an attempt is made to run it on a computer where there is a pre-existing installation of Atom... you see the issue.

I'd strongly urge you to implement it as a portable app according to the PortableApps.com spec: http://portableapps.com/development

[batjko]

Not that violently, @paulcbetts: That solution would still require an installation and, as @proimage mentions, wouldn't allow parallel running of both (which is a fringe case, but still).

Is it a huge effort to maintain a fully independent portable release - i.e. without conditional launch mode checking, and without an installer, just the ready-to-go folder with a local .atom inside the release directory?

[iliyang]

I agree that it could be a pain to maintain a PortableApps-style release. I, and I also hope most other users, would be perfectly happy with an .atom folder inside the installation folder, as long as everything remains completely encapsulated and no files are written anywhere outside the installation folder. Such a simple structure would also hopefully facilitate automatic updates.

[anaisbetts]

Is it a huge effort to maintain a fully independent portable release - i.e. without conditional launch mode checking, and without an installer, just the ready-to-go folder with a local .atom inside the release directory?

I think it'd probably be super easy, I might try to make a patch for it

[sketchpunk]

A year ago I made a copy mostly portable by simply having a .atom folder in the application's folder. The only real issue is duplication and hardcoded values through out the app to determines the location of the .atom folder. Ideally there should be a single global function or variable that holds the location of the .atom folder, then the rest of the app and all plugins get the value from this global func/var. In good api design this is how an app should be setup. I would of done these myself but I dont like coffeescript and I feel it was a mistake to use coffee script in developing atom, but that's another issue entirely. The changes I did was to the javascript of the compiled atom btw. Look at previous comments and examples I made in this thread literally a year ago. Which is kinda sad that after a year this is still an issue.

[dead-claudia]

I would prefer to have a simple zip file. It's easier to set up and use
than a PortableApps installer. And I'm already used to a similar workflow
with the Linux global install version. My school uses Windows almost
exclusively, which necessitates having a portable version to take around.
It would be incredibly convenient.

On Wed, Aug 19, 2015, 10:51 sketchpunk notifications@github.com wrote:

A year ago I made a copy mostly portable by simply having a .atom folder
in the application's folder. The only real issue is duplication and
hardcoded values through out the app to determines the location of the
.atom folder. Ideally there should be a single global function or variable
that holds the location of the .atom folder, then the rest of the app and
all plugins get the value from this global func/var. In good api design
this is how an app should be setup. I would of done these myself but I dont
like coffeescript and I feel it was a mistake to use coffee script in
developing atom, but that's another issue entirely. The changes I did was
to the javascript of the compiled atom btw. Look at previous comments and
examples I made in this thread literally a year ago. Which is kinda sad
that after a year this is still an issue.

—
Reply to this email directly or view it on GitHub
#2939 (comment).

[proimage]

No reason not to have both.

FYI, one major advantage PortableApps has over just a zip is that it offers automatic app updates.

[nengxu]

+1 for portable mode

[softwarespot]

+1

[kdmaas]

+1 for portable mode

[kdmaas]

@IMPinball
Am I missing something?
If you don't want to use the PortableApps menu you can use the self-extracting zip-files directly.
You'll have to remember to update manually though.

[dead-claudia]

@kdmaas

It's not so much the menu. I just prefer unzipping a zipball in a few steps through the standard instead of clicking through about 6-10 screens in a pretty useless GUI that does effectively the same thing.

Unless Atom modifies the registry (which it doesn't appear to, even in a global install), I don't think there would be much advantage to an installer that is just a glorified self-extracting zip file. You might as well use 7-zip for that - it would accomplish the same thing.

I also don't think that there would be a lot of work to make this zip-file portable. IMHO it would be easiest if Atom included a way to change the user path (i.e. the return value of os.homedir()) at the time of initialization. It's something that could also be done via setting the %userprofile% variable in a way local to the application.

[ghost]

+1

[dumpsters]

+1, only thing keeping me from using atom.
Maybe checking if there is a ".portable_mode" dotfile in atom's directory and saving configs and packages to "./.portable_data/"

[Sisyphuss]

+1

[capSAR273]

Just chiming in with my support for a portable version, I use Atom off of a flash drive for coursework and losing custom settings/packages is less than optimal. I'll try the suggestions put here by others until Atom is truly portable 👍

[jamescostian]

👍

[Ivan171]

+1

[javiglesias]

+1

[bhack]

👍

[thomasjo]

This is being worked on in #8442, so there is no need to +1 this and in so doing, notifying 52 people. As a result, I'm locking this issue for the time being. Feel free to subscribe to the PR if you're curious about the progress being made.

[anaisbetts]

This is now merged into master as part of #8442 and friends, and will show up in the next release! Thanks for the feedback all

[benogle]

💥 🎉