Mailing List Archive: SPF: Devel

pyspf packaging

Index | Next | Previous | View Threaded

stuart at bmsi

Dec 18, 2006, 11:18 AM

Post #1 of 20 (3203 views)
Permalink

pyspf packaging

I wish to provide multiple DNS drivers for pyspf.
There are 3 options for providing them:

1) a single file (spf.py) will all drivers. A default driver is selected
on first use, unless user selects one first. This is ScottKs preferred
choice.

2) a package named spf:

spf/
pyspf.py
pydns.py
dnspython.py
pyip6.py

This is the preferred choice of com.lang.python. You lose the ability
to run the spf.py script as a command line query. They recommend
using spfquery.py or equivalent instead. Disclaimer, they are
python experts but don't use pyspf.

3) A module named spf and a package named SPF:

spf.py
SPF/
pydns.py
dnspython.py
pyip6.py

This preserves the use of spf.py as a script, and provides separate
files for drivers, making additional drivers as easy to add as 2).

Petr of the ppolicyd project prefers 2) or 3). He says a driver for
'adns' would be nice. ScottK mentions 'twisted' as another python
dns package. (When will the standard library include DNS?)

I have committed option 3 to CVS as a compromise between ScottK and 2).
ScottK is unhappy at having to copy a file and a directory, instead of
just a file. (The drivers will change rarely, and mostly he just needs
to copy a file.)

Comments?

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 11:34 AM

Post #2 of 20 (3122 views)
Permalink

Re: pyspf packaging [In reply to]

On Monday 18 December 2006 14:18, Stuart D. Gathman wrote:

> I have committed option 3 to CVS as a compromise between ScottK and 2).
> ScottK is unhappy at having to copy a file and a directory, instead of
> just a file. (The drivers will change rarely, and mostly he just needs
> to copy a file.)

Thanks. The only things I'd add to that discussion are:

1. pyspf has functioned as a single file since it was released in 2003.
Changing the file structure in a non-backward compatible way after 3 years is
a signficant issue. I think your option 3 sounds like a way to move forward
(I think supporting multiple DNS drivers is a good thing since the primary
DNS driver pyspf uses has been unmaintained for a long time) while
maintaining compatibliity.

2. Most Linux distributions still package version 1.6. Until packaging
catches up to where most people will use their packaging system to install
pyspf, we ought to keep it as simple as possible.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 18, 2006, 11:51 AM

Post #3 of 20 (3127 views)
Permalink

Re: pyspf packaging [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> I wish to provide multiple DNS drivers for pyspf.
> There are 3 options for providing them:
>
> 1) a single file (spf.py) will all drivers. A default driver is
> selected on first use, unless user selects one first. This is ScottKs
> preferred choice.
>
> 2) a package named spf:
> [...]
>
> 3) A module named spf and a package named SPF:
> [...]

I think that generally the conventions of the language should be honored,
so that would be (2).

> ScottK is unhappy at having to copy a file and a directory, instead of
> just a file.

Sorry, Scott, but I think this is not a legitimate concern with the broad
availability of packaging systems these days. :-) So I'd rule out (1).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFhvE/wL7PKlBZWjsRAj1HAJ9tYHTiUTrKQKWFnS5D0oZcDJoyPQCg4IVL
WxED+6t0yM1y20kd1e9Pti4=
=oKxJ
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 18, 2006, 11:53 AM

Post #4 of 20 (3118 views)
Permalink

Re: pyspf packaging [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> Most Linux distributions still package version 1.6. Until packaging
> catches up to where most people will use their packaging system to
> install pyspf, we ought to keep it as simple as possible.

Can't we prod them into updating their packages?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFhvGswL7PKlBZWjsRAsI3AKDDH5MHOMcfd2BhLUj+S3KxPmOBWQCdGQfw
yCmGUOVvaQa7mrqGpmlX9MY=
=/Wk+
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 12:16 PM

Post #5 of 20 (3143 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Monday 18 December 2006 14:53, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > Most Linux distributions still package version 1.6. Until packaging
> > catches up to where most people will use their packaging system to
> > install pyspf, we ought to keep it as simple as possible.
>
> Can't we prod them into updating their packages?
>
Certainly.

I was thinking of Stuart's option 3 as a transition approach while packaging
catches up.

Once I can apt-get install python-spf and get a version greater than 2.1, I'll
be happy to switch to Stuart's option 2.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 1:36 PM

Post #6 of 20 (3112 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Monday 18 December 2006 14:53, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > Most Linux distributions still package version 1.6. Until packaging
> > catches up to where most people will use their packaging system to
> > install pyspf, we ought to keep it as simple as possible.
>
> Can't we prod them into updating their packages?
>
Along these lines, I've started working on a Debian package for pyspf 2.1.

Stuart: Would you please update the README to correctly describe the new
method for command line queries. What's in there now is obsolete since you
re-arranged stuff.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 18, 2006, 2:10 PM

Post #7 of 20 (3137 views)
Permalink

Re: pyspf packaging [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> I wish to provide multiple DNS drivers for pyspf.
> There are 3 options for providing them:
>
> [...]
>
> 2) a package named spf:
> [...]
> This is the preferred choice of com.lang.python. You lose the
> ability to run the spf.py script as a command line query. They
> recommend using spfquery.py or equivalent instead. [...]

A few weeks ago I suggested on #spf that an `spfquery` command-line tool be
included in the pyspf package that supports an interface compatible to the
other spfquery tools out there (libspf2's, Mail::SPF::Query's,
Mail::SPF's).

I think the interface of older spfquery implementations (libspf2, M:S:Q) is
not very powerful, though. Compare:

http://spf.pastecode.com/10244 (libspf2 1.2.5)
http://spf.pastecode.com/10242 (Mail::SPF::Query 1.997)

to:

http://spf.pastecode.com/10245 (Mail::SPF)
http://search.cpan.org/dist/Mail-SPF/bin/spfquery (ditto)

(Mail::SPF still supports the old interface, though.)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFhxHUwL7PKlBZWjsRAhVJAKCFPOrS1goe72e/5MfN0G0kZBvB8gCg+5yP
GUUM1mlwSdvHfSdUrmeGRw4=
=PIXR
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 2:26 PM

Post #8 of 20 (3134 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Monday 18 December 2006 17:10, Julian Mehnle wrote:
> Stuart D. Gathman wrote:
> > I wish to provide multiple DNS drivers for pyspf.
> > There are 3 options for providing them:
> >
> > [...]
> >
> > 2) a package named spf:
> > [...]
> > This is the preferred choice of com.lang.python. You lose the
> > ability to run the spf.py script as a command line query. They
> > recommend using spfquery.py or equivalent instead. [...]
>
> A few weeks ago I suggested on #spf that an `spfquery` command-line tool be
> included in the pyspf package that supports an interface compatible to the
> other spfquery tools out there (libspf2's, Mail::SPF::Query's,
> Mail::SPF's).
>
> I think the interface of older spfquery implementations (libspf2, M:S:Q) is
> not very powerful, though. Compare:
>
> http://spf.pastecode.com/10244 (libspf2 1.2.5)
> http://spf.pastecode.com/10242 (Mail::SPF::Query 1.997)
>
> to:
>
> http://spf.pastecode.com/10245 (Mail::SPF)
> http://search.cpan.org/dist/Mail-SPF/bin/spfquery (ditto)
>
> (Mail::SPF still supports the old interface, though.)

After we discussed that, I did look and there is an existing sfpyquery.py with
pyspf. I've just never used it, because I always just called pyspf directly.
I have not looked at it's interface yet.

BTW, this will take some rework for my validator too.

I'll do the work to make the transition, but I'll wait for Stuart to update
the documentation.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 18, 2006, 3:34 PM

Post #9 of 20 (3143 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006, Scott Kitterman wrote:

> Along these lines, I've started working on a Debian package for pyspf 2.1.
>
> Stuart: Would you please update the README to correctly describe the new
> method for command line queries. What's in there now is obsolete since you
> re-arranged stuff.

You'll notice than in CVS I took option 3. This still allows using
spy.py on command line and with -m. Are you now in the option 2 camp?

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 18, 2006, 4:02 PM

Post #10 of 20 (3141 views)
Permalink

Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006, Scott Kitterman wrote:

> On Monday 18 December 2006 14:18, Stuart D. Gathman wrote:
>
> > I have committed option 3 to CVS as a compromise between ScottK and 2).
> > ScottK is unhappy at having to copy a file and a directory, instead of
> > just a file. (The drivers will change rarely, and mostly he just needs
> > to copy a file.)
>
> 1. pyspf has functioned as a single file since it was released in 2003.
> Changing the file structure in a non-backward compatible way after 3 years is
> a signficant issue. I think your option 3 sounds like a way to move forward
> (I think supporting multiple DNS drivers is a good thing since the primary
> DNS driver pyspf uses has been unmaintained for a long time) while
> maintaining compatibliity.

The choice between 2) and 3) is permanent. It would be really
ugly to rename the 'SPF' package to 'spf' once it was distributed.
The only drawback to 3) is using two names in the root package namespace.
Since the two names are 'spf' and 'SPF', this isn't too bad. Note,
that this works with case preserving systems like Windows because
modules have the '.py*' extension. (At least I'm pretty sure it does.
Maybe someone with Windows should give it a try.)

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 4:14 PM

Post #11 of 20 (3141 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006 18:34:56 -0500 (EST) "Stuart D. Gathman"
<stuart [at] bmsi> wrote:
>On Mon, 18 Dec 2006, Scott Kitterman wrote:
>
>> Along these lines, I've started working on a Debian package for pyspf
2.1.
>>
>> Stuart: Would you please update the README to correctly describe the
new
>> method for command line queries. What's in there now is obsolete since
you
>> re-arranged stuff.
>
>You'll notice than in CVS I took option 3. This still allows using
>spy.py on command line and with -m. Are you now in the option 2 camp?

I like option 1 the best.

I think it should be option 1 or 2 for the long run. I like option 2
better than 3 for the long run. The key to option 2 (which is more complex
in some repects for the end user) is packaging, so I think packaging for
various distros is even more important than in the past.

So, I am working on a Debian package for 2.1.

Since your preferred approach requires a change in the README for command
line use, I'd appreciate it if you'd make those changes.

I still prefer option 1, but prefer 2 over 3 eventually. 3 is a good way
to go for the moment.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 4:18 PM

Post #12 of 20 (3141 views)
Permalink

Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006 19:02:29 -0500 (EST) "Stuart D. Gathman"
<stuart [at] bmsi> wrote:

>The choice between 2) and 3) is permanent. It would be really
>ugly to rename the 'SPF' package to 'spf' once it was distributed.
>The only drawback to 3) is using two names in the root package namespace.
>Since the two names are 'spf' and 'SPF', this isn't too bad. Note,
>that this works with case preserving systems like Windows because
>modules have the '.py*' extension. (At least I'm pretty sure it does.
>Maybe someone with Windows should give it a try.)

OK. Then nevermind. I vote 3.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 18, 2006, 4:47 PM

Post #13 of 20 (3145 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006, Scott Kitterman wrote:

> Since your preferred approach requires a change in the README for command
> line use, I'd appreciate it if you'd make those changes.

So you'd like me to mention spfquery in README even though option 3
is currently in CVS head?

> I still prefer option 1, but prefer 2 over 3 eventually. 3 is a good way
> to go for the moment.

I think the choice between 2 and 3 has to be permanent. We don't want
to rename the driver package down the road.

This is what I think I'm hearing from you:

1) change CVS to option 2 (make a branch tag?)
2) update README to talk about spfquery
3) 2.0.x will stay with single spf.py module
4) 2.1.x will use option 2 (spf package)

Does that match your current thinking?

BTW, spfquery should have an option to run doctests for spf package,
since spf package won't do so anymore.

Comment: IMO, spfquery, as currently consituted (to be compatible with
other spf packages), is a Royal Pain to use compared with spf.py.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 5:58 PM

Post #14 of 20 (3132 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006 19:47:54 -0500 (EST) "Stuart D. Gathman"
<stuart [at] bmsi> wrote:
>On Mon, 18 Dec 2006, Scott Kitterman wrote:
>
>> Since your preferred approach requires a change in the README for
command
>> line use, I'd appreciate it if you'd make those changes.
>
>So you'd like me to mention spfquery in README even though option 3
>is currently in CVS head?
>
>> I still prefer option 1, but prefer 2 over 3 eventually. 3 is a good
way
>> to go for the moment.
>
>I think the choice between 2 and 3 has to be permanent. We don't want
>to rename the driver package down the road.

Understand that now. The following comments are based on not doing option
1 (still my preference).

>This is what I think I'm hearing from you:
>
> 1) change CVS to option 2 (make a branch tag?)

Yes. With thr branch tag.

> 2) update README to talk about spfquery

For 2.1 and follow.

> 3) 2.0.x will stay with single spf.py module

Yes.

> 4) 2.1.x will use option 2 (spf package)

Yes.

I'll (when I have time) make a Debian package for 2.1 and will maintain the
2.0 branch (I'll backport changes from 2.1 that look
interesting/necessary).

I'd suggest you set up 2.1 with spfquery so that an existing call to spy.py
can be changed to spfquery.py with no syntax changes (that makes changing
command line calls easy). Supporting the other spfquery interfaces would
be nice if feasible, but lower priority.
>
>Does that match your current thinking?

Yes (more detail than I'd thought through, but yes).

>BTW, spfquery should have an option to run doctests for spf package,
>since spf package won't do so anymore.

I think this is mandatory.

>Comment: IMO, spfquery, as currently consituted (to be compatible with
>other spf packages), is a Royal Pain to use compared with spf.py.

OK. I haven't looked at it. See my coment above.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 18, 2006, 8:00 PM

Post #15 of 20 (3143 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Mon, 18 Dec 2006, Scott Kitterman wrote:

> I'd suggest you set up 2.1 with spfquery so that an existing call to spy.py
> can be changed to spfquery.py with no syntax changes (that makes changing
> command line calls easy). Supporting the other spfquery interfaces would
> be nice if feasible, but lower priority.

With option 2, we can still call the script spf.py. The package 'spf' will
take precedence on import. Thus, scripts would be unchanged. But
users might be confused at having both an spf.py script and an 'spf' package.
For instance, copying the spf.py script somewhere would not allow them
to "import spf". They must copy the spf directory for that.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 18, 2006, 9:08 PM

Post #16 of 20 (3139 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Monday 18 December 2006 23:00, Stuart D. Gathman wrote:
> On Mon, 18 Dec 2006, Scott Kitterman wrote:
> > I'd suggest you set up 2.1 with spfquery so that an existing call to
> > spy.py can be changed to spfquery.py with no syntax changes (that makes
> > changing command line calls easy). Supporting the other spfquery
> > interfaces would be nice if feasible, but lower priority.
>
> With option 2, we can still call the script spf.py. The package 'spf' will
> take precedence on import. Thus, scripts would be unchanged. But
> users might be confused at having both an spf.py script and an 'spf'
> package. For instance, copying the spf.py script somewhere would not allow
> them to "import spf". They must copy the spf directory for that.

I'm after backward compatibility. As much as it as we can reasonably get.

We absolutely need to be able to run the test suite from the the command line.

If your new spf.py script could cover that requirement too, the might be
helpful.

Given that we are going to work hard to get pyspf 2.1 packaged for the major
distributions, I think command line functional compatibility (calling spf.py
on the command line so people don't have to modify scripts) and making the
test suite easily invokable from the command line are more important than
ease of installation. So, I think that's the way to go. Just need to make
the documentation clear.

To recap:

pyspf < 2.1 is option one in a CVS branch that I will maintain for some period
of time.

pyspf >= 2.1 is option two. I'll do a Debian package and someone else (you or
whoever you can talk into it) will do an RPM package.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 20, 2006, 4:15 AM

Post #17 of 20 (3122 views)
Permalink

Re: pyspf packaging [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> The only drawback to 3) is using two names in the root package
> namespace. Since the two names are 'spf' and 'SPF', this isn't too bad.
> Note, that this works with case preserving systems like Windows because
> modules have the '.py*' extension. (At least I'm pretty sure it does.
> Maybe someone with Windows should give it a try.)

You can NOT have both "spf.py" and "SPF.py" in a single directory on FAT or
NTFS partitions.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFiSlxwL7PKlBZWjsRArTwAJ996k511mqNlmQSIJLTpDjbwFywOACg/Dpl
WyefWyWC3uh5QEpEMo+F+O4=
=Po9f
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 20, 2006, 7:53 AM

Post #18 of 20 (3102 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Wed, 20 Dec 2006, Julian Mehnle wrote:

> Stuart D. Gathman wrote:
> > The only drawback to 3) is using two names in the root package
> > namespace. Since the two names are 'spf' and 'SPF', this isn't too bad.
> > Note, that this works with case preserving systems like Windows because
> > modules have the '.py*' extension. (At least I'm pretty sure it does.
> > Maybe someone with Windows should give it a try.)
>
> You can NOT have both "spf.py" and "SPF.py" in a single directory on FAT or
> NTFS partitions.

And you wont. You will have "spf.py" and a directory called "SPF".
Even on a case insensitive, non-preserving system, you can have both
the module and the package. The issue is knowing which to use given
the name 'spf' or 'SPF'. With a case preserving system, you know which
to use, but the module/package lookup logic would be different from unix,
and python for Windows might not cater to this. (Although python isn't
shy about supporting platform specific stuff.)

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 20, 2006, 8:44 AM

Post #19 of 20 (3101 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Monday 18 December 2006 19:47, Stuart D. Gathman wrote:

...
> 1) change CVS to option 2 (make a branch tag?)
...
> 3) 2.0.x will stay with single spf.py module
...

If you could go ahead and make the branch tag for 2.0.1, I'd appreciate it.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

stuart at bmsi

Dec 21, 2006, 9:00 PM

Post #20 of 20 (3107 views)
Permalink

Re: Re: pyspf packaging [In reply to]

On Wed, 20 Dec 2006, Scott Kitterman wrote:

> If you could go ahead and make the branch tag for 2.0.1, I'd appreciate it.

I made a branch tag pyspf-2_0-branch, and merged your comma heuristic
into it.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads