Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #57975 > unrolled thread

personal library

Back to article view | Back to comp.lang.python

Contents

  personal library patrick vrijlandt <patrick.vrijlandt@gmail.com> - 2013-10-29 21:29 +0000
    Re: personal library Dave Angel <davea@davea.name> - 2013-10-30 02:00 +0000
    Re: personal library Chris Angelico <rosuav@gmail.com> - 2013-10-30 15:26 +1100
      Re: personal library Paul Rudin <paul.nospam@rudin.co.uk> - 2013-10-30 06:31 +0000
    Re: personal library Ben Finney <ben+python@benfinney.id.au> - 2013-10-30 15:33 +1100
    Re: personal library Chris Angelico <rosuav@gmail.com> - 2013-10-30 15:48 +1100
      Re: personal library patrick vrijlandt <patrick.vrijlandt@gmail.com> - 2013-10-30 20:02 +0000
        Re: personal library Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-31 07:19 +1100
        Re: personal library Ben Finney <ben+python@benfinney.id.au> - 2013-10-31 07:37 +1100
        Re: personal library Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 21:52 +0100
        Re: personal library paul.nospam@rudin.co.uk - 2013-10-30 20:34 +0000
        Re: personal library Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 21:08 +0000
          Re: personal library Grant Edwards <invalid@invalid.invalid> - 2013-10-30 21:20 +0000
        Re: personal library Chris Angelico <rosuav@gmail.com> - 2013-10-31 08:31 +1100
          Re: personal library patrick vrijlandt <patrick.vrijlandt@gmail.com> - 2013-10-31 21:48 +0000
        Re: personal library Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-31 08:43 +1100
        Re: personal library Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-31 08:45 +1100
      Re: personal library rusi <rustompmody@gmail.com> - 2013-10-31 20:38 -0700

#57975 — personal library

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!

-- 
patrick

[toc] | [next] | [standalone]

#57993

On 29/10/2013 17:29, patrick vrijlandt wrote:

> 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.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#58002

On Wed, Oct 30, 2013 at 1:00 PM, Dave Angel <davea@davea.name> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#58008

Chris Angelico <rosuav@gmail.com> writes:

> On Wed, Oct 30, 2013 at 1:00 PM, Dave Angel <davea@davea.name> wrote:
>> 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.
>

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.

[toc] | [prev] | [next] | [standalone]

#58004

Chris Angelico <rosuav@gmail.com> writes:

> *Definitely* use source control.

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

-- 
 \        “This sentence contradicts itself — no actually it doesn't.” |
  `\                                               —Douglas Hofstadter |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#58005

On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> *Definitely* use source control.
>
> +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

[toc] | [prev] | [next] | [standalone]

#58106

Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>> 
>>> *Definitely* use source control.
>> 
>> +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

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

-- 
patrick

[toc] | [prev] | [next] | [standalone]

#58109

[Multipart message — attachments visible in raw view] — view raw

On 31 October 2013 07:02, patrick vrijlandt <patrick.vrijlandt@gmail.com>wrote:

> Chris Angelico <rosuav@gmail.com> wrote:
> > On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney <ben+python@benfinney.id.au>
> wrote:
> >> Chris Angelico <rosuav@gmail.com> writes:
> >>
> >>> *Definitely* use source control.
> >>
> >> +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
>
> 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

[toc] | [prev] | [next] | [standalone]

#58111

patrick vrijlandt <patrick.vrijlandt@gmail.com> writes:

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

My vote is for Bazaar <URL:http://bazaar.canonical.com/> for its
excellent user interface and workflow support.

-- 
 \           “Oh, I love your magazine. My favorite section is ‘How To |
  `\          Increase Your Word Power’. That thing is really, really, |
_o__)                          really... good.” —Homer, _The Simpsons_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#58114

Op 30-10-13 21:02, patrick vrijlandt schreef:
> Chris Angelico <rosuav@gmail.com> wrote:
>> On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>>> Chris Angelico <rosuav@gmail.com> writes:
>>>
>>>> *Definitely* use source control.
>>>
>>> +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
> 
> 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.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#58118

patrick vrijlandt <patrick.vrijlandt@gmail.com> writes:


> 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. 

[toc] | [prev] | [next] | [standalone]

#58119

On 30/10/2013 20:52, Antoon Pardon wrote:
> Op 30-10-13 21:02, patrick vrijlandt schreef:
>> Chris Angelico <rosuav@gmail.com> wrote:
>>> On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>>>> Chris Angelico <rosuav@gmail.com> writes:
>>>>
>>>>> *Definitely* use source control.
>>>>
>>>> +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
>>
>> 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.
>

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... :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#58123

On 2013-10-30, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 30/10/2013 20:52, Antoon Pardon wrote:
>
>> So start a small project and try to use a number of them simultaneously
>> and then decide which feels more natural to you.
>
> 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)

-- 
Grant Edwards               grant.b.edwards        Yow! I'm a fuschia bowling
                                  at               ball somewhere in Brittany
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#58126

On Thu, Oct 31, 2013 at 7:19 AM, Tim Delaney
<timothy.c.delaney@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#58208

Chris Angelico <rosuav@gmail.com> wrote:
> 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!

-- 
patrick

[toc] | [prev] | [next] | [standalone]

#58132

[Multipart message — attachments visible in raw view] — view raw

On 31 October 2013 08:31, Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Oct 31, 2013 at 7:19 AM, Tim Delaney
> <timothy.c.delaney@gmail.com> wrote:
> > 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?


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

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#58133

[Multipart message — attachments visible in raw view] — view raw

On 31 October 2013 08:43, Tim Delaney <timothy.c.delaney@gmail.com> wrote:

> On 31 October 2013 08:31, Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Thu, Oct 31, 2013 at 7:19 AM, Tim Delaney
>> <timothy.c.delaney@gmail.com> wrote:
>> > 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?
>
>
> 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

[toc] | [prev] | [next] | [standalone]

#58234

On Wednesday, October 30, 2013 10:18:20 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Oct 30, 2013 at 3:33 PM, Ben Finney  wrote:
> > Chris Angelico  writes:
> >> *Definitely* use source control.
> > +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.

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.
--------

So from that POV both 'source code' and 'version control' are
misnomers. So -- as usually happens in our field -- the acronym DVCS
becomes the closest non-misnomer to a really new concept

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web