On 29Apr2015 22:10, boB Stepp <robertvst...@gmail.com> wrote:
On Wed, Apr 29, 2015 at 9:40 PM, Cameron Simpson <c...@zip.com.au> wrote:
On 29Apr2015 12:12, boB Stepp <robertvst...@gmail.com> wrote:
... (3) install git if needed ...
It seems Git is needed, but I am not allowed to install it on the
Solaris workstation. So is there a way around this?
What do you mean by "install"? Bear in mind that while you may be forbidden
from installing git in the main areas (/usr, /usr/local, whatever), you may
be free to install it in your own home directory. It is just an
executable...
On the smart enterprise where we (now) do our clinical planning they
are very strict: no installing any external software; no accessing the
Internet; no email; etc. Not all centers adhere to this level of
strictness, but ours does. [...] But I am reluctant to do
anything that I am not allowed to replicate on smart enterprise. I am
trying to keep it as close to identical to the actual clinical
environment as I can.
And fair enough too. I frequently wish our developers' dev environments more
rigorously modelled the target environment.
Perhaps this is misguided on my part?
Not necessarily.
But I would be inclined to distinguish your working tools from the target
environment.
For example, I commend you making your dev environment as close to identical to
the actual clinical environment as you can. But I wouldn't deprive yourself of
tools that enhance your code management practices without affecting that
environment.
For example, there is much to be said for tracking your changes with a tool
like git or hg. It encourages your to annotate your changes, and lets you
review history to see when and why some change occurred, especially if a new
bug has arisen. Distributed version control systems like git and hg also make
it easier to work on distinct changes to the same code as separate work
processes; of course the price for such a workflow is that you need to merge
the two things later and ensure that they do not interact badly.
If you're serious about keeping the two environments very similar, you could
always do your _coding_ on a third platform (a laptop or whatever) using your
desired tools and _deploy_ the code to the dev (and later, prod) environments
from there, keeping the dev environment pristine. By "deploy", that can be as
simple as copying the code to the target.
Just thoughts; of course you must choose practices that suit your needs and
plans.
Cheers,
Cameron Simpson <c...@zip.com.au>
Nothing is impossible for the man who doesn't have to do it.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
