<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 22, 2014 at 7:40 AM, Maniteja Nandana <span dir="ltr"><<a href="mailto:maniteja.modesty067@gmail.com" target="_blank">maniteja.modesty067@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thank you for the suggestion. I will remember this as a viable option. As of now, I have a virtual machine of ubuntu running on Windows. So, I wanted to have least overhead while running the VM.</div></div></div></div></blockquote><div><br></div><div>As a note, virtual environments and conda environments are NOT like virtual machines -- they add no runtime overhead whatsoever -- they do add some disk space overhead if that's an issue (though conda environments use hard linking wherever possible, so very little of that, either)</div><div><br></div><div>If you have a production use of python/numpy then it would be very helpful to use a *environment system to keep your development work separate from your production work. If not, then no reason not to work in the "<br>main" python environment.</div><div><br></div><div>A few other notes:</div><div><br></div><div>* You can certainly do numpy development on Windows, too, if you're more comfortable there.</div><div><br></div><div>* I highly recommend "develop mode" when working on packages:</div><div><br></div><div>   python setup.py develop.</div><div><br></div><div>   What that does is put links in to the package source location, rather than copying it into the python installation. That way, it looks like it's installed (you don't need to do any path manipulations or change imports), but changes to the source will be immediately available (if it's compiled extensiun, they do need to be re-compiled, of course, which running setup.py develop again will do.</div><div><br></div><div>* You are right, you can't accidentally mess up the main master branch when you are working in a clone -- you don't have the permissions to do that, and your clone is completely independent anyway. However, it's a good idea to make a brach for a particular feature experiment, as it:</div><div>  - keeps thing cleaner an easier to keep tack of for your own work flow.</div><div>  - make it much easier to create a merg-able pull request if you decide you's like to contribute your work back to the main project.</div><div><br></div><div>I'd read up on the git workflow to get an idea how to do all this. This:</div><div><br></div><div><a href="https://sandofsky.com/blog/git-workflow.html">https://sandofsky.com/blog/git-workflow.html</a><br></div><div><br></div><div>Is a pretty good intro -- and there are many others.</div><div><br></div><div>HTH.</div><div> -Chris</div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>