personal library

[patrick vrijlandt]

Hello list,

Python has been a hobby for me since version 1.5.2. Over the years I
accumulated quite a lot of reusable code. It is nicely organised in
modules, directories and subdirectories. With every project, the library
grows and is developed further. I would like to ask your advice for two
problems:

For most projects I use python's most recent, stable release. Obviously,
some 3rd party libraries still do not support Python3 (like wx) and I will
use 2.7. Does this mean I should maintain seperate libraries for 2 and 3,
or can this be done easier? I do like new language features!

How do I arrange that I can access the most recent version of my library on
every computer in my home network? Development is usually on my desktop,
sometimes on my laptop, and of course I use python for maintenance tasks on
other computers in the house (e.g. The children's). I now have the library
on a network share and local copies on each computer, but of course I
forget to synchronise often enough.

As said, python is a hobby, and the solution should be as lightweight as
possible! I'm usually on windows (vista, xp or 7).

Thanks!

 

[Dave Angel]

Hello list,

Python has been a hobby for me since version 1.5.2. Over the years I
accumulated quite a lot of reusable code. It is nicely organised in
modules, directories and subdirectories. With every project, the library
grows and is developed further. I would like to ask your advice for two
problems:

For most projects I use python's most recent, stable release. Obviously,
some 3rd party libraries still do not support Python3 (like wx) and I will
use 2.7. Does this mean I should maintain seperate libraries for 2 and 3,
or can this be done easier? I do like new language features!

Two approaches are feasible here. Best would be to change your
library code (usually in minor ways) so that it just works on both
version 2.7 and 3.x That would mainly involve including from __future__
imports inside a conditional clause - based on version check. Many of
the most painful differences have been back ported to 2.7

If that's just not doable, then write the code such that either 2to3 or
3to2 will convert your master copy to the other state. If you can avoid
separately editing the two versions, bug will be lots easier to contain.
(see https://wiki.python.org/moin/3to2 but I haven't ever used
it)

How do I arrange that I can access the most recent version of my library on
every computer in my home network? Development is usually on my desktop,
sometimes on my laptop, and of course I use python for maintenance tasks on
other computers in the house (e.g. The children's). I now have the library
on a network share and local copies on each computer, but of course I
forget to synchronise often enough.

First, I haven't seen any mention of a source control system. Get one,
learn it, and use it. That should always hold your master copy. And
the actual repository should be on a system you can access from any of
the others.

Then, once you can get to such a repository, you use it to sync your
various local copies on your individual machines. You could have the
synch happen automatically once a day, or whatever. You could also
build an auto-synch utility which pushed the synch from the server
whenever the server was updated.

If you're always going to be using these machines with real-time access
to the central server, you could use Windows shares to avoid needing any
updates. Just create a share on the server, and mount it on each of the
clients. Add it to your system.path and you're done.

I don't like that last answer because I'm frequently *don't* have access
even to the internet, never mind to a particular server.

 

[Chris Angelico]

First, I haven't seen any mention of a source control system. Get one,
learn it, and use it. That should always hold your master copy. And
the actual repository should be on a system you can access from any of
the others.

Then, once you can get to such a repository, you use it to sync your
various local copies on your individual machines. You could have the
synch happen automatically once a day, or whatever. You could also
build an auto-synch utility which pushed the synch from the server
whenever the server was updated.

If you're always going to be using these machines with real-time access
to the central server, you could use Windows shares to avoid needing any
updates. Just create a share on the server, and mount it on each of the
clients. Add it to your system.path and you're done.

I don't know about Mercurial, but with git it's pretty easy to set up
a post-push hook that gets run whenever new changes hit the server.

From there, you could have some registered replicas that get

immediately told to pull, which will give fairly immediate
replication. It's not actually real-time, but you have a guarantee
that they're up-to-date - if any change gets missed, it'll be caught
in the next update. It'd take a little work to set up, but you could
have something almost as convenient as shared folders but without the
messes and risks.

*Definitely* use source control.

ChrisA

 

[Chris Angelico]

+1, but prefer to call it a “version control system” which is (a) more
easily searched on the internet, and (b) somewhat more accurate.

Right. I've picked up some bad habits, and I think Dave may also
have... but yes, "distributed version control system" is what I'm
talking about here.

ChrisA

 

[Paul Rudin]

I don't know about Mercurial, but with git it's pretty easy to set up
a post-push hook that gets run whenever new changes hit the server.
immediately told to pull, which will give fairly immediate
replication. It's not actually real-time, but you have a guarantee
that they're up-to-date - if any change gets missed, it'll be caught
in the next update. It'd take a little work to set up, but you could
have something almost as convenient as shared folders but without the
messes and risks.

*Definitely* use source control.

Indeed. Also note that there's nothing per se wrong with putting your
repositories on Dropbox or similar - especially in a single user
situation. I do this so as to keep things synced across different
machines. You don't always want to check stuff in as you move from
e.g. laptop to desktop, but you do want to be able to pick up where you
left off on the other machine.

 

[patrick vrijlandt]

Right. I've picked up some bad habits, and I think Dave may also
have... but yes, "distributed version control system" is what I'm
talking about here.

ChrisA

Thanks. Do you all agree that Mercurial is the way to go, or is there
another "distributed version control system" that I should shortlist?

 

[Tim Delaney]

Thanks. Do you all agree that Mercurial is the way to go, or is there
another "distributed version control system" that I should shortlist?

There are huge arguments all over the net on this topic. Having extensively
used the top two contenders (Git and Mercurial) I would strongly advise you
to use Mercurial.

What it comes down to for me is that Mercurial usage fits in my head and I
rarely have to go to the docs, whereas with Git I have to constantly go to
the docs for anything but the most trivial usage - even when it's something
I've done many times before. I'm always afraid that I'm going to do
something *wrong* in Git.

Tim Delaney

 

[Guest]

Thanks. Do you all agree that Mercurial is the way to go, or is there
another "distributed version control system" that I should shortlist?

git is popular too. In the long run it's probably worth getting
experience with both.

 

[Antoon Pardon]

Op 30-10-13 21:02, patrick vrijlandt schreef:

Thanks. Do you all agree that Mercurial is the way to go, or is there
another "distributed version control system" that I should shortlist?

This is a question that only you can answer trough experience. I started
out with bazaar, tried out git at bit and finaly ended up using mercurial
but others have followed their own trail.

So start a small project and try to use a number of them simultaneously
and then decide which feels more natural to you.

 

[Grant Edwards]

And if the worst comes to the worst there's always Visual Source Safe.
Starts running with trenching tool, camouflage net, tin hat, flak
jacket...

VSS: it's what makes Clearcase seem like a good idea(TM)

 

[Chris Angelico]

What it comes down to for me is that Mercurial usage fits in my head and I
rarely have to go to the docs, whereas with Git I have to constantly go to
the docs for anything but the most trivial usage - even when it's something
I've done many times before. I'm always afraid that I'm going to do
something *wrong* in Git.

Oddly enough, I've had the opposite experience. With git, I can do
whatever I want easily, but with Mercurial, some tasks seem to elude
me. (Is there a "Mercurial cheat-sheet for git users" somewhere? I'm
looking for things like creating an emailable patch from a commit,
pulling in the latest updates while keeping my own changes (I think
rebase is a hg plugin??), and ideally, some approximate equivalent to
gitk as a visual representation of the repo.)

But yeah. Either git or hg will serve you well, and Bazaar (bzr) also
has its advocates. Getting to know all three (or at least git/hg) to
at least some extent will serve you well - at least be comfortable
enough with the basics to clone someone else's project, pull changes
from upstream, and see where it's at.

ChrisA

 

[Tim Delaney]

Oddly enough, I've had the opposite experience. With git, I can do
whatever I want easily, but with Mercurial, some tasks seem to elude
me. (Is there a "Mercurial cheat-sheet for git users" somewhere?

https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

Tim Delaney

 

[Tim Delaney]

https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

And the defacto standard GUI for Mercurial is TortoiseHg (available on
Windows, Linux and OSX).

Tim Delaney

 

[patrick vrijlandt]

On Thu, Oct 31, 2013 at 7:19 AM, Tim Delaney
But yeah. Either git or hg will serve you well, and Bazaar (bzr) also
has its advocates. Getting to know all three (or at least git/hg) to
at least some extent will serve you well - at least be comfortable
enough with the basics to clone someone else's project, pull changes
from upstream, and see where it's at.

ChrisA

Thank you all. I will download and start learning!

 

[rusi]

Right. I've picked up some bad habits, and I think Dave may also
have... but yes, "distributed version control system" is what I'm
talking about here.

There is this article by Joel Spolsky
http://www.joelonsoftware.com/items/2010/03/17.html
-- putatively around mercurial but really about modern distributed
version control systems (DVCS). He says:

---------
With distributed version control, the distributed part is actually not
the most interesting part.

The interesting part is that these systems think in terms of changes,
not in terms of versions.