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

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

Re: sick of distribute, setup, and all the rest...

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: sick of distribute, setup, and all the rest... Cameron Simpson <cs@zip.com.au> - 2011-11-28 08:46 +1100
    Re: sick of distribute, setup, and all the rest... rusi <rustompmody@gmail.com> - 2011-11-27 20:25 -0800
      Re: sick of distribute, setup, and all the rest... Roy Smith <roy@panix.com> - 2011-11-27 23:31 -0500

#16298 — Re: sick of distribute, setup, and all the rest...

On 27Nov2011 23:54, Matt Joiner <anacrolix@gmail.com> wrote:
| Agreed. I recently gave Haskell a go, and it was remarkable how
| similar the package management is to Python's.
| 
| How well does the new "packaging" (set for release in Python 3.3?)
| module deal with the problems?
| 
| With a better package management system, the half of the standard
| library that nobody uses can be unceremoniously dumped, and their more
| recent upstream versions used correctly. Even distutils itself is
| "obsolete", the first recommendation people give is to replace it with
| distribute and/or pip.

Ah the cheery optimism of the end user.
Package systems have a lot of fun complications.

Install for the user only? For the whole system?
Architecture specific?
What if people want access to different versions of a package?
What about vendor supplied (eg RPM) versus user obtained? They'll fight,
one way or another. What if policy has user supplied installing to its
own tree (sensible to avoid conflicts) - the fetch/install kit need to
know this.
What about stability? Your "half of the standard library that nobody uses can
be unceremoniously dumped, and their more recent upstream versions used
correctly" leads to bugs in the apps that use the packages if they depend on
particular versions/APIs. The stdlib is generally quite careful about
breaking APIs but other packagers often are less so.

I can make this list bigger or more detailed if you want.  All package
systems have these issues. They're not as trivial as you might imagine.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

The problem with elections is that the government always wins.
        - Chris Rudram <csr100@unix.york.ac.uk>

[toc] | [next] | [standalone]

#16307

On Nov 28, 2:46 am, Cameron Simpson <c...@zip.com.au> wrote:
> On 27Nov2011 23:54, Matt Joiner <anacro...@gmail.com> wrote:
> | Agreed. I recently gave Haskell a go, and it was remarkable how
> | similar the package management is to Python's.
> |
> | How well does the new "packaging" (set for release in Python 3.3?)
> | module deal with the problems?
> |
> | With a better package management system, the half of the standard
> | library that nobody uses can be unceremoniously dumped, and their more
> | recent upstream versions used correctly. Even distutils itself is
> | "obsolete", the first recommendation people give is to replace it with
> | distribute and/or pip.
>
> Ah the cheery optimism of the end user.
> Package systems have a lot of fun complications.
>
> Install for the user only? For the whole system?
> Architecture specific?
> What if people want access to different versions of a package?
> What about vendor supplied (eg RPM) versus user obtained? They'll fight,
> one way or another. What if policy has user supplied installing to its
> own tree (sensible to avoid conflicts) - the fetch/install kit need to
> know this.
> What about stability? Your "half of the standard library that nobody uses can
> be unceremoniously dumped, and their more recent upstream versions used
> correctly" leads to bugs in the apps that use the packages if they depend on
> particular versions/APIs. The stdlib is generally quite careful about
> breaking APIs but other packagers often are less so.
>
> I can make this list bigger or more detailed if you want.  All package
> systems have these issues. They're not as trivial as you might imagine.

Where is there any implication that there are not issues or that they
are trivial?
At the end of his life Dijkstra said: The single biggest problem in
computer science is how not to make a mess of it; that problem remains
unsolved.

The OP simply expressed a wish for improvement and I seconded that
[and pls ignore ranters with oedipal problems]

From my post from a few months http://mail.python.org/pipermail/python-list/2011-May/1271765.html

If I may restate:
Too much mindshare is devoted to all the linguistic features of
python: garbage collection, identation, metaclasses and all that other
good stuff from the 70s and too little to extra-linguistic ecosystem
features below:

If the linguistic features were all that mattered Lisp would be the
king of languages today


>
> >    | Area             | Tool(s)                |
> >    |------------------+------------------------|
> >    | packaging        | distutils, setuptools, |
> >    |                  | distutils2, distribute |
> >    |                  | Native tools (eg apt)  |
> >    | versioning       | hg, git, bzr           |
> >    | multiple pythons | virtualenv             |
> >    | ??               | tox                    |
> >    | testing          | unittest, nose, pytest |
> >    | build            | scons, make...         |
> >    | deployment       | fabric                 |
>

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

#16308

In article 
<46c11371-411a-4ba0-89b9-967e2f83e942@k5g2000pre.googlegroups.com>,
 rusi <rustompmody@gmail.com> wrote:

> If the linguistic features were all that mattered Lisp would be the
> king of languages today

(that (is (one (of (the (most (absurd (statements (I've (read (in (a 
(long (time))))))))))))))

[toc] | [prev] | [standalone]

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

csiph-web