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

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

Does python have built command for package skeleton creation?

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

Contents

  Does python have built command for package skeleton creation? xliiv <tymoteusz.jankowski@gmail.com> - 2012-09-21 03:07 -0700
    Re: Does python have built command for package skeleton creation? Tarek Ziadé <tarek@ziade.org> - 2012-09-21 13:08 +0200
      Re: Does python have built command for package skeleton creation? xliiv <tymoteusz.jankowski@gmail.com> - 2012-09-21 05:14 -0700
        Re: Does python have built command for package skeleton creation? Tarek Ziadé <tarek@ziade.org> - 2012-09-21 15:04 +0200
          Re: Does python have built command for package skeleton creation? xliiv <tymoteusz.jankowski@gmail.com> - 2012-09-21 06:13 -0700
            Re: Does python have built command for package skeleton creation? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-21 14:50 +0100
              Re: Does python have built command for package skeleton creation? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-21 15:54 +0000
                Re: Does python have built command for package skeleton creation? Dave Angel <d@davea.name> - 2012-09-21 13:26 -0400
                  Re: Does python have built command for package skeleton creation? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-21 17:31 +0000
                Re: Does python have built command for package skeleton creation? Chris Angelico <rosuav@gmail.com> - 2012-09-22 03:44 +1000
                  Re: Does python have built command for package skeleton creation? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-22 01:43 +0000
                    Re: Does python have built command for package skeleton creation? Chris Angelico <rosuav@gmail.com> - 2012-09-22 12:00 +1000
                Re: Does python have built command for package skeleton creation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-21 16:04 -0400
          Re: Does python have built command for package skeleton creation? xliiv <tymoteusz.jankowski@gmail.com> - 2012-09-21 06:13 -0700
            Re: Does python have built command for package skeleton creation? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-09-24 11:54 -0700
            Re: Does python have built command for package skeleton creation? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-09-24 11:54 -0700
        Re: Does python have built command for package skeleton creation? alex23 <wuwei23@gmail.com> - 2012-09-23 20:59 -0700
          Re: Does python have built command for package skeleton creation? Terry Reedy <tjreedy@udel.edu> - 2012-09-24 00:28 -0400
            Re: Does python have built command for package skeleton creation? alex23 <wuwei23@gmail.com> - 2012-09-23 22:00 -0700
            Re: Does python have built command for package skeleton creation? Ramchandra Apte <maniandram01@gmail.com> - 2012-09-23 22:33 -0700
            Re: Does python have built command for package skeleton creation? Ramchandra Apte <maniandram01@gmail.com> - 2012-09-23 22:33 -0700
      Re: Does python have built command for package skeleton creation? xliiv <tymoteusz.jankowski@gmail.com> - 2012-09-21 05:14 -0700

Page 1 of 2  [1] 2  Next page →

#29617 — Does python have built command for package skeleton creation?

Like the topic.. . I found this:

http://learnpythonthehardway.org/book/ex46.html

it seems fine, but shouldn't be an interactive (with CLI API) script creating that? It's a lot of effort for common work.

I can contribute but i have to know that i'm not reinvent a wheel.

[toc] | [next] | [standalone]

#29620

On 9/21/12 12:07 PM, xliiv wrote:
> Like the topic.. . I found this:
>
> http://learnpythonthehardway.org/book/ex46.html
>
> it seems fine, but shouldn't be an interactive (with CLI API) script creating that? It's a lot of effort for common work.
>
> I can contribute but i have to know that i'm not reinvent a wheel.
>
>
Python Paste is probably what you are looking for - see 
http://lucasmanual.com/mywiki/PythonPaste for example

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

#29621

On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
> On 9/21/12 12:07 PM, xliiv wrote:
> 
> > Like the topic.. . I found this:
> 
> >
> 
> > http://learnpythonthehardway.org/book/ex46.html
> 
> >
> 
> > it seems fine, but shouldn't be an interactive (with CLI API) script creating that? It's a lot of effort for common work.
> 
> >
> 
> > I can contribute but i have to know that i'm not reinvent a wheel.
> 
> >
> 
> >
> 
> Python Paste is probably what you are looking for - see 
> 
> http://lucasmanual.com/mywiki/PythonPaste for example

It's a nice beast but:
- it's not built in. Should it be? I think it should.
- about readme and manifest.in:
"You could add to your template a file called readme.rst . Inside of it you can add the following code that will generate this:"

i dont want to add, i want it already added :).. readme is something typical, it's not rare habit for some geeks how wants to customize it all!! the same with manifest.in..

what do you think? iteractive creation is big plus..

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

#29625

On 9/21/12 2:14 PM, xliiv wrote:
>
> Python Paste is probably what you are looking for - see
>
> http://lucasmanual.com/mywiki/PythonPaste for example
> It's a nice beast but:
> - it's not built in. Should it be? I think it should.
You can suggest this to python-ideas but I really doubt you will get any 
traction. The sdtlib don't get new features these days because it's a burden
to maintain high level tool on a 2 years release cycle

> - about readme and manifest.in:
> "You could add to your template a file called readme.rst . Inside of it you can add the following code that will generate this:"
>
> i dont want to add, i want it already added :).. readme is something typical, it's not rare habit for some geeks how wants to customize it all!! the same with manifest.in..
>
> what do you think? iteractive creation is big plus..

I am not sure I get your remark on this. I pointed to this page to show 
a typical use case of building Paster Templates, so you can bootstrap 
your projects boiler-plate code

So IOW everyone's free to create any kind of template :)

Cheers
Tarek

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

#29626

On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> On 9/21/12 2:14 PM, xliiv wrote:
> 
> >
> 
> > Python Paste is probably what you are looking for - see
> 
> >
> 
> > http://lucasmanual.com/mywiki/PythonPaste for example
> 
> > It's a nice beast but:
> 
> > - it's not built in. Should it be? I think it should.
> 
> You can suggest this to python-ideas but I really doubt you will get any 
> 
> traction. The sdtlib don't get new features these days because it's a burden
> 
> to maintain high level tool on a 2 years release cycle

Why is this '2 years release cycle'?

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

#29633

On 21/09/2012 14:13, xliiv wrote:
> On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
>> On 9/21/12 2:14 PM, xliiv wrote:
>>
>>>
>>
>>> Python Paste is probably what you are looking for - see
>>
>>>
>>
>>> http://lucasmanual.com/mywiki/PythonPaste for example
>>
>>> It's a nice beast but:
>>
>>> - it's not built in. Should it be? I think it should.
>>
>> You can suggest this to python-ideas but I really doubt you will get any
>>
>> traction. The sdtlib don't get new features these days because it's a burden
>>
>> to maintain high level tool on a 2 years release cycle
>
> Why is this '2 years release cycle'?
>

Because there aren't enough volunteers to get it done any faster?

-- 
Cheers.

Mark Lawrence.

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

#29649

On Fri, 21 Sep 2012 14:50:36 +0100, Mark Lawrence wrote:

> On 21/09/2012 14:13, xliiv wrote:

>> Why is this '2 years release cycle'?
>>
>>
> Because there aren't enough volunteers to get it done any faster?

Because if it were any faster, it would piss off a lot of people.

Python's release cycle is actually closer to 18 months for minor releases
(3.2 -> 3.3, for example), and 10 years for major releases (2.x -> 3.x). 
But consider, C and C++ don't have minor releases *at all*. The last 
versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS 
since the last version of C++. And Java hasn't had a major feature update 
since 2006.

For a programming language with a lot of corporate use, Python already 
seems like it changes at the drop of a hat.


-- 
Steven

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

#29653

On 09/21/2012 11:54 AM, Steven D'Aprano wrote:
> On Fri, 21 Sep 2012 14:50:36 +0100, Mark Lawrence wrote:
>
>> On 21/09/2012 14:13, xliiv wrote:
>>> Why is this '2 years release cycle'?
>>>
>>>
>> Because there aren't enough volunteers to get it done any faster?
> Because if it were any faster, it would piss off a lot of people.
>
> Python's release cycle is actually closer to 18 months for minor releases
> (3.2 -> 3.3, for example), and 10 years for major releases (2.x -> 3.x). 
> But consider, C and C++ don't have minor releases *at all*. The last 
> versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS 
> since the last version of C++. And Java hasn't had a major feature update 
> since 2006.

"C++0x was the working name of a new ISO C++ standard, which was then
released in 2011 as C++11  ..."
   according to  http://gcc.gnu.org/projects/cxx0x.html

And it replaced C++03, released in 2003.



> For a programming language with a lot of corporate use, Python already 
> seems like it changes at the drop of a hat.
>
>
Correct.

-- 

DaveA

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

#29656

On Fri, 21 Sep 2012 13:26:32 -0400, Dave Angel wrote:

> On 09/21/2012 11:54 AM, Steven D'Aprano wrote:

>> Python's release cycle is actually closer to 18 months for minor
>> releases (3.2 -> 3.3, for example), and 10 years for major releases
>> (2.x -> 3.x). But consider, C and C++ don't have minor releases *at
>> all*. The last versions of those two languages are C99 and C+98 --
>> that's FOURTEEN YEARS since the last version of C++. And Java hasn't
>> had a major feature update since 2006.
> 
> "C++0x was the working name of a new ISO C++ standard, which was then
> released in 2011 as C++11  ..."
>    according to  http://gcc.gnu.org/projects/cxx0x.html
> 
> And it replaced C++03, released in 2003.

I stand corrected, thank you.


-- 
Steven

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

#29660

On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> But consider, C and C++ don't have minor releases *at all*. The last
> versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS
> since the last version of C++. And Java hasn't had a major feature update
> since 2006.
>
> For a programming language with a lot of corporate use, Python already
> seems like it changes at the drop of a hat.

Hang on, you're conflating the language and its implementation. C and
C++ don't have minor releases, because you're looking only at the
language. On the other hand, gcc has major.minor.revision releases,
because it's possible for the compiler to have trivial bugs that merit
a small bugfix, or minor changes that perhaps enhance the stdlib.

The way I see it, a Python minor release shouldn't normally be a
problem to an active developer, but is too big a change to push
quietly to active scripts. That's a lot smaller than a release of a
new C/C++ spec; more akin to the next version of Microsoft Visual C++,
which comes out every couple of years ish. And as DaveA (no relation
to me, but I love the coincidence of surname AND signature style)
pointed out, there have been C++ spec updates since 98.

Python's release schedule is plenty fast enough. It's already
outstripping the packagers in Debian and Red Hat. Fortunately it's
pretty easy to whip up your own Python straight from source and 'make
altinstall' to keep things happily parallel. You want faster releases?
You got 'em.

ChrisA

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

#29709

On Sat, 22 Sep 2012 03:44:55 +1000, Chris Angelico wrote:

> On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> But consider, C and C++ don't have minor releases *at all*. The last
>> versions of those two languages are C99 and C+98 -- that's FOURTEEN
>> YEARS since the last version of C++. And Java hasn't had a major
>> feature update since 2006.
>>
>> For a programming language with a lot of corporate use, Python already
>> seems like it changes at the drop of a hat.
> 
> Hang on, you're conflating the language and its implementation. 

No I'm not. CPython is the reference implementation of Python the 
language. There is no ISO standard for Python (nor is there likely to be 
any time soon) so Python the language is more-or-less what CPython the 
implementation does.


[...]
> Python's release schedule is plenty fast enough. It's already
> outstripping the packagers in Debian and Red Hat. 

And has for a long time, well back to Python 1.5 days if I remember 
correctly.


> Fortunately it's
> pretty easy to whip up your own Python straight from source and 'make
> altinstall' to keep things happily parallel. You want faster releases?
> You got 'em.

But not faster than ≈18 months between minor releases. Not unless you 
fork and do it yourself.



-- 
Steven

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

#29712

On Sat, Sep 22, 2012 at 11:43 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 22 Sep 2012 03:44:55 +1000, Chris Angelico wrote:
>
>> On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> For a programming language with a lot of corporate use, Python already
>>> seems like it changes at the drop of a hat.
>>
>> Hang on, you're conflating the language and its implementation.
>
> No I'm not. CPython is the reference implementation of Python the
> language. There is no ISO standard for Python (nor is there likely to be
> any time soon) so Python the language is more-or-less what CPython the
> implementation does.

True, though not entirely; there are plenty of CPython behaviours that
aren't strictly specified, and other Pythons don't have to comply.

>> Fortunately it's
>> pretty easy to whip up your own Python straight from source and 'make
>> altinstall' to keep things happily parallel. You want faster releases?
>> You got 'em.
>
> But not faster than ≈18 months between minor releases. Not unless you
> fork and do it yourself.

Why wait for a release? Just build with whatever patches you want to
build with. That's what I do with a lot of oddments of software. Well,
actually, what I tend to do is simply build HEAD (or whatever hg calls
it) as of when I want it, and update whenever I feel like it. :)

ChrisA

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

#29669

On Sat, 22 Sep 2012 03:44:55 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> The way I see it, a Python minor release shouldn't normally be a
> problem to an active developer, but is too big a change to push
> quietly to active scripts. That's a lot smaller than a release of a

	Before my lay-off I'd been tasked to examine a version complication
on systems at work.

	I'd produced a few scripts under Python 2.3... They /should/ be
workable under any later 2.x version (the only externals were [at the
time] ctypes, PMW, and maybe one other library). BUT -- out of fear the
organization kept installing 2.3 [and its a good thing I'd kept a CD of
my original installation disk for the scripts].

	Problem -- one system had a script written by someone else that used
Python 2.2 AND had a custom binary DLL. My scripts couldn't be
downgraded to 2.2 as they /did/ rely on features new in 2.3.

	And I couldn't find the source code for that custom DLL to enable
building for a newer Python. Don't know if they ever tracked down the
author of that program to find out how to upgrade it.

	Sole reason they needed this unification? They were adding that 2.2
system to the ClearCase controlled network -- and my 2.3 scripts were
the ones that automated the loading of specified "builds" from ClearCase
onto the runtime hardware.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#29627

On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> On 9/21/12 2:14 PM, xliiv wrote:
> 
> >
> 
> > Python Paste is probably what you are looking for - see
> 
> >
> 
> > http://lucasmanual.com/mywiki/PythonPaste for example
> 
> > It's a nice beast but:
> 
> > - it's not built in. Should it be? I think it should.
> 
> You can suggest this to python-ideas but I really doubt you will get any 
> 
> traction. The sdtlib don't get new features these days because it's a burden
> 
> to maintain high level tool on a 2 years release cycle

Why is this '2 years release cycle'?

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

#29917

xliiv於 2012年9月21日星期五UTC+8下午9時13分38秒寫道：
> On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> 
> > On 9/21/12 2:14 PM, xliiv wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > Python Paste is probably what you are looking for - see
> 
> > 
> 
> > >
> 
> > 
> 
> > > http://lucasmanual.com/mywiki/PythonPaste for example
> 
> > 
> 
> > > It's a nice beast but:
> 
> > 
> 
> > > - it's not built in. Should it be? I think it should.
> 
> > 
> 
> > You can suggest this to python-ideas but I really doubt you will get any 
> 
> > 
> 
> > traction. The sdtlib don't get new features these days because it's a burden
> 
> > 
> 
> > to maintain high level tool on a 2 years release cycle
> 
> 
> 
> Why is this '2 years release cycle'?

This is good in python to focus on comming HW patforms with 
varied parameters as the industry is advacing toward  all way 
to avoid a heavy landing of the IT and electronics industry.

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

#29918

xliiv於 2012年9月21日星期五UTC+8下午9時13分38秒寫道：
> On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> 
> > On 9/21/12 2:14 PM, xliiv wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > Python Paste is probably what you are looking for - see
> 
> > 
> 
> > >
> 
> > 
> 
> > > http://lucasmanual.com/mywiki/PythonPaste for example
> 
> > 
> 
> > > It's a nice beast but:
> 
> > 
> 
> > > - it's not built in. Should it be? I think it should.
> 
> > 
> 
> > You can suggest this to python-ideas but I really doubt you will get any 
> 
> > 
> 
> > traction. The sdtlib don't get new features these days because it's a burden
> 
> > 
> 
> > to maintain high level tool on a 2 years release cycle
> 
> 
> 
> Why is this '2 years release cycle'?

This is good in python to focus on comming HW patforms with 
varied parameters as the industry is advacing toward  all way 
to avoid a heavy landing of the IT and electronics industry.

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

#29891

On Sep 21, 10:14 pm, xliiv <tymoteusz.jankow...@gmail.com> wrote:
> On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
> > Python Paste is probably what you are looking for - see

> It's a nice beast but:
> - it's not built in. Should it be? I think it should.

There needs to be a distinction at some point between Python as
runtime and development environments. If you assume that there are
more users of Python code than developers, then cluttering it with
more developer-only tools is a waste of resources for those end users.

Also: developers are fussy about their environments. One person's vi
is another person's emacs. We keep various package skeletons in our
git repository, and that works well for us, so adding Paste to Python
is just more useless kruft from our perspective.

And: easy_install/pip install paste isn't exactly crippling to type.

> - about readme and manifest.in:
> "You could add to your template a file called readme.rst"
> i dont want to add, i want it already added :)

If you'd just did as they asked, you'd already have this issue
resolved by now.

If you're waiting for the standard library to scratch your itch for
you, you're going to be waiting for a long, _long_ time.

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

#29892

On 9/23/2012 11:59 PM, alex23 wrote:
> On Sep 21, 10:14 pm, xliiv <tymoteusz.jankow...@gmail.com> wrote:
>> On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
>>> Python Paste is probably what you are looking for - see
>
>> It's a nice beast but:
>> - it's not built in. Should it be? I think it should.
>
> There needs to be a distinction at some point between Python as
> runtime and development environments. If you assume that there are
> more users of Python code than developers, then cluttering it with
> more developer-only tools is a waste of resources for those end users.
>
> Also: developers are fussy about their environments. One person's vi
> is another person's emacs. We keep various package skeletons in our
> git repository, and that works well for us, so adding Paste to Python
> is just more useless kruft from our perspective.
>
> And: easy_install/pip install paste isn't exactly crippling to type.
>
>> - about readme and manifest.in:
>> "You could add to your template a file called readme.rst"
>> i dont want to add, i want it already added :)
>
> If you'd just did as they asked, you'd already have this issue
> resolved by now.
>
> If you're waiting for the standard library to scratch your itch for
> you, you're going to be waiting for a long, _long_ time.

Batteries are batteries, not flashlights, phone, radios, toys, clickers, 
etc.

-- 
Terry Jan Reedy

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

#29894

On Sep 24, 2:29 pm, Terry Reedy <tjre...@udel.edu> wrote:
> Batteries are batteries, not flashlights, phone, radios, toys, clickers,
> etc.

I decided not to mention "venv" as it undermines my rant a little :)

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

#29898

On Monday, 24 September 2012 09:59:12 UTC+5:30, Terry Reedy  wrote:
> On 9/23/2012 11:59 PM, alex23 wrote:
> 
> > On Sep 21, 10:14 pm, xliiv <tymoteusz.jankow...@gmail.com> wrote:
> 
> >> On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
> 
> >>> Python Paste is probably what you are looking for - see
> 
> >
> 
> >> It's a nice beast but:
> 
> >> - it's not built in. Should it be? I think it should.
> 
> >
> 
> > There needs to be a distinction at some point between Python as
> 
> > runtime and development environments. If you assume that there are
> 
> > more users of Python code than developers, then cluttering it with
> 
> > more developer-only tools is a waste of resources for those end users.
> 
> >
> 
> > Also: developers are fussy about their environments. One person's vi
> 
> > is another person's emacs. We keep various package skeletons in our
> 
> > git repository, and that works well for us, so adding Paste to Python
> 
> > is just more useless kruft from our perspective.
> 
> >
> 
> > And: easy_install/pip install paste isn't exactly crippling to type.
> 
> >
> 
> >> - about readme and manifest.in:
> 
> >> "You could add to your template a file called readme.rst"
> 
> >> i dont want to add, i want it already added :)
> 
> >
> 
> > If you'd just did as they asked, you'd already have this issue
> 
> > resolved by now.
> 
> >
> 
> > If you're waiting for the standard library to scratch your itch for
> 
> > you, you're going to be waiting for a long, _long_ time.
> 
> 
> 
> Batteries are batteries, not flashlights, phone, radios, toys, clickers, 
> 
> etc.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

Do remember to include laptops.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web