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


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

Sharing code between different projects?

Started byandrea crotti <andrea.crotti.0@gmail.com>
First post2012-08-13 17:53 +0100
Last post2012-08-14 15:35 +0000
Articles 2 — 2 participants

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


Contents

  Sharing code between different projects? andrea crotti <andrea.crotti.0@gmail.com> - 2012-08-13 17:53 +0100
    Re: Sharing code between different projects? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-14 15:35 +0000

#26999 — Sharing code between different projects?

Fromandrea crotti <andrea.crotti.0@gmail.com>
Date2012-08-13 17:53 +0100
SubjectSharing code between different projects?
Message-ID<mailman.3235.1344876821.4697.python-list@python.org>
I am in the situation where I am working on different projects that
might potentially share a lot of code.

I started to work on project A, then switched completely to project B
and in the transiction I copied over a lot of code with the
corresponding tests, and I started to modify it.

Now it's time to work again on project A, but I don't want to copy
things over again.

I would like to design a simple and nice way to share between projects,
where the things I want to share are simple but useful things as for
example:

class TempDirectory:
    """Create a temporary directory and cd to it on enter, cd back to
    the original position and remove it on exit
    """
    def __init__(self):
        self.oldcwd = getcwd()
        self.temp_dir = mkdtemp()

    def __enter__(self):
        logger.debug("create and move to temp directory %s" % self.temp_dir)
        return self.temp_dir

    def __exit__(self, type, value, traceback):
        # I first have to move out
        chdir(self.oldcwd)
        logger.debug("removing the temporary directory and go back to
the original position %s" % self.temp_dir)
        rmtree(self.temp_dir)


The problem is that there are functions/classes from many domains, so it
would not make much sense to create a real project, and the only name I
could give might be "utils or utilities"..

In plus the moment the code is shared I must take care of versioning and
how to link different pieces together (we use perforce by the way).

If then someone else except me will want to use these functions then of
course I'll have to be extra careful, designing really good API's and so
on, so I'm wondering where I should set the trade-off between ability to
share and burden to maintain..

Anyone has suggestions/real world experiences about this?

[toc] | [next] | [standalone]


#27047

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2012-08-14 15:35 +0000
Message-ID<502a7058$0$29978$c3e8da3$5496439d@news.astraweb.com>
In reply to#26999
On Mon, 13 Aug 2012 17:53:32 +0100, andrea crotti wrote:

> I started to work on project A, then switched completely to project B
> and in the transiction I copied over a lot of code with the
> corresponding tests, and I started to modify it.
> 
> Now it's time to work again on project A, but I don't want to copy
> things over again.
>
> I would like to design a simple and nice way to share between projects,
> where the things I want to share are simple but useful things as for
> example:
[...]
> The problem is that there are functions/classes from many domains, so it
> would not make much sense to create a real project, and the only name I
> could give might be "utils or utilities"..

I feel your pain. "Copy and paste" is perhaps the simplest, most 
seductive, and *worst* of the developer anti-patterns.

I wish I had a solution to share with you, because I'm in the same 
position, but I don't.

The best I have come up with is a combination of:

1) For really small code snippets, just forget about sharing code. If you 
need a five-line function Foo in ten projects, just re-write them (well, 
copy and paste them...) each time. Forget about trying to keep them 
syncronised.


2) For bigger functions/classes, put them in their own module which you 
can share across multiple projects.


3) Consider having a "utilities" module to include all the assorted bits 
and pieces.


If your projects are in-house, then a utilities module makes more sense. 
If you're writing libraries for independent release, not so much.



-- 
Steven

[toc] | [prev] | [standalone]


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


csiph-web