On Thu, Jan 13, 2000 at 01:55:19PM -0500, Joe Block wrote:
> David Coe wrote:
> >
> > > I do think task-python(*) makes sense. But I think a "python" package
> > > would just encourage people to make gratuitous overarching
> > > dependencies...
> >
> > Another good point.
>
> Part of the proble
David Coe wrote:
>
> > I do think task-python(*) makes sense. But I think a "python" package
> > would just encourage people to make gratuitous overarching
> > dependencies...
>
> Another good point.
Part of the problem is that there doesn't seem to be a tool yet to
automatically figure out whi
Chris Lawrence <[EMAIL PROTECTED]> writes:
> On Jan 13, Gregor Hoffleit wrote:
> > ...I still like the idea of a
> > real python package--IMHO it's a little bit more intuitive than task-python,
> > ...
> > Finally, and perhaps most important, a real "python" package would make
> > versioned depen
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> Do we prefer our packages to use tk8.2 or on tk8.0 ?
I'd like to suggest to keep Tk 8.0. That is what is usually used by
Python on most if not all platforms, and it is well-tested.
On Jan 13, Gregor Hoffleit wrote:
> Ok, maybe we better go with task-python, although I still like the idea of a
> real python package--IMHO it's a little bit more intuitive than task-python,
> and if the name is still free, why shouldn't we use it.
I do think task-python(*) makes sense. But I th
On Wed, Jan 12, 2000 at 04:00:01PM -0500, David Coe wrote:
> This sounds like a task package to me, too, but maybe I misunderstand
> what you said; would it include anything besides the dependencies?
>
> Also note that we still have (well, recently had, at least) some packages
> which depend on
6 matches
Mail list logo