Handling differences between engineering organizations

[professor]

I'm transitioning from Labs to the Data organization. They have very specific installation needs that the other Labs offices will not need or use.

I'm assuming we'd create a new bash script that runs after engineer.sh, that is unique to each organization? (e.g. cf-engineer.sh, data-engineer.sh)

But where do store that script? a) in this github repo b) somewhere else (different github repo, google drive, etc.)

Thoughts?

[cjcjameson]

I'm happy to start contributing to this effort. I would be happy for this to live in a pivotal/* repo rather than the pivotal-DataFabric org.

To catalogue what scripts I know of floating around right now:

• https://github.com/d/minature-happiness
• https://github.com/zaksoup/zotfiles
• https://github.com/zaksoup/zimfiles
• https://github.com/Pivotal-DataFabric/ci-infrastructure/blob/master/lib/tasks/prerequisites.rake

One option which I don't like: forking this repo into the pivotal-datafabric org

@mtan @d @zaksoup @edespino @amilkh for more info

[amilkh]

I definitely agree that we should first do the workstation-setup scripts to get a baseline and then put the Data-specific steps after this. For reference, here is the living guide I made: https://docs.google.com/document/d/1QpyH8ebV6qgU6W_uXMzt_F8LLBsvfmhRGvhKaJByYkA/edit

[nertzy]

I'm all for having different scripts in this repo. I think it'd be a great way for the various orgs to share tooling.

I can imagine renaming engineer.sh to labs-engineer.sh and then making a second copy called data-engineer.sh and modifying it as needed. That way, people using this repo can mostly have just one script to run instead of needing to run engineer.sh followed by data-engineer.sh, etc.

[professor]

Cool. I imagine that there are common items (flycut, shiftit, brew, git, etc) that would be shared across the company, and worth being in a common script. I don't know what is specific to labs yet, so I don't know what I would put in a shared-engineer.sh vs labs-engineer.sh yet

[amilkh]

Just had a discussion with @cjcjameson and @professor. We went through the script repos that C.J. mentioned above and below is what Data should have installed:

clion
docker #mac beta
wget
ccache
autocon
ctags
cscope
cmake
#scriptized version of the below guide
https://docs.google.com/document/d/1QpyH8ebV6qgU6W_uXMzt_F8LLBsvfmhRGvhKaJByYkA/edit#

As for modifying the workstation-setup repo, we were thinking to have a special script called data-engineer.sh, which will install the Data-specific requirements, after having installed everything used by Pivotal Labs Engineers (engineer.sh).

[professor]

ccache and ctags both have warnings.

ccache

NOTE: ccache can prevent some software from compiling.
ALSO NOTE: The brew command, by design, will never use ccache.

ctags

Under some circumstances, emacs and ctags can conflict. By default,
emacs provides an executable `ctags` that would conflict with the
executable of the same name that ctags provides. To prevent this,
Homebrew removes the emacs `ctags` and its manpage before linking.

However, if you install emacs with the `--keep-ctags` option, then
the `ctags` emacs provides will not be removed. In that case, you
won't be able to install ctags successfully. It will build but not
link.

[amilkh]

Hmm, on a GPDB Catalog & Storage workstation, we never installed ccache, but did do brew install etags and brew install ctags. I don't remember the ctags error message and here is the current output:

creekside:gpdemo pivotal$ brew install ctags
Warning: ctags-5.8_1 already installed

[nertzy]

I wouldn't worry too much about the ctags warning. From what it says, it sounds like they worked around it pretty well. Presumably someone who uses emacs's version of ctags a lot would already be familiar with how Homebrew sets things up, and otherwise things are probably fine going with the Homebrew defaults.

[nertzy]

@amilkh you're not seeing the warning because you already have it installed.

If you run brew info ctags you can read the Caveats section again after you've installed it.

[nertzy]

Also for the ccache one, I read that as "Hey guess what, if you use ccache too aggressively things can break, and that's on you. But we disable it when compiling things with Homebrew." which is perhaps useful editorial commentary but not really anything to particularly do anything about.

[amilkh]

Thank you @nertzy!