OK, there were a bunch of messages in this thread, so rather than
replying to them individually...
On 25/08/12 04:46, Doug Coleman wrote:
> Python's package management is terrible. They have easy_install,
> distribute, distribute2, pip, and virtualenv, in addition to having
> binaries/interpreters/libraries for python2 and python3. I tried pip
> but it couldn't install one of the packages I needed, so I wiped them
> all and went back to easy_install.
OK, so there's two things here: the Python tools for downloading and
installing packages, and the Python package-metadata standards that make
the tools possible.
I freely admit that the existing Python tools are terrible, but we're
talking about package-metadata here. Python's package-metadata is good
enough that I can take pretty much any standard Python package, and
quickly (i.e. within ten minutes) turn that into a workable distro
package for Debian or RedHat. Actual Debian or Fedora packagers can do
an even better job; the net result is that I rarely if ever need to mess
with easy_install, pip, or distribute because "apt-get install
python-foo" or "yum install python-foo" Just Works.
I'm just hoping that Factor packages will be as easy for distro
developers to package.
> Everything is global and I find
> myself having to edit config files and rm directories/egg files by
> hand to upgrade packages.
Yeah, that's exactly the kind of mess I avoid by sticking with distro
packages.
> I had a ".11-git" release of a library, and
> even though ".11" was out, easy_install wouldn't upgrade it. You have
> to micromanage each installed package.
That's a good point - that sort of thing happens because (up until
recently) the official Python package repository hasn't enforced any
kinds of standards on version numbering. That's changing with PEP 0396:
http://www.python.org/dev/peps/pep-0396/
...so hopefully that should get better over time. I notice that the Gist
linked in the original post just describes the package version attribute
as "a string identifying the version of the package", so it might be a
good idea to rigorously define how version numbers should be parsed and
compared, so that Factor can avoid the same fate.
Marmaduke Woodman <mmwood...@gmail.com> wrote:
> Some Linux distros do manage to keep their python packages current,
> but the Python project
> I work on (with 30+ dependencies) distributes all the deps with the
> package or requests users
> to use pip or easy_install because version numbers of Python packages
> across Linuxes seem
> to follow a log normal distribution.
Sure, there's always scenarios where you need packages your distro
doesn't include, or newer versions than your distro supplies. That's not
every situation, though - for myself, I know I'm much more likely to
download and experiment with a tool, language or library if I can use
the packaging system I already know. Even if it's a bit older than the
latest release, or doesn't have quite the same breadth of packages
available, the convenience more than outweighs those drawbacks.
I'm not saying everybody must always use distro packages for everything,
just that some people are always going to prefer them, so it's worth
considering what will help distros keep their packages up to date. From
my limited experience, a good part of that is "statically defined,
machine-parsable package metadata", which is already in the proposed
spec, so that's good!
Joe Groff <arc...@gmail.com> wrote:
> I'd call this a plus, because Debian's update schedule is glacial, and
> you don't want to be limited by your system package manager when
> installing a library for yourself for a local project.
Well... as I mentioned above, often I *would*. If I decided to check out
a new tool "Foo" for the first time, and I had to decide between
installing the package provided by my distro (whom I already trust to
curate the rest of my OS), versus following setup/installation
instructions from some wiki-page somewhere that might be out of date, or
irrelevant to my particular OS, or maybe my Google-fu has failed and I'm
looking at entirely the wrong page... yeah, I'm going to go with the
distro package at least until I've learned enough to make an educated
decision.
Aside from that, everybody I know who runs Debian runs Unstable or at
least Testing, which are quite good at staying up-to-date even if the
Stable release is... very stable.
> Systems like
> gem and npm let you easily install up-to-date packages at a user- or
> project-local location without requiring admin access or coordination
> with the system's update schedule.
And Factor should totally have such a tool - for the benefit of users
who want to stay on the cutting edge, and for the benefit of users on
platforms like Mac OS X and Windows that don't have proper
package-managers. My point is just that Factor on its own is quite
different from more mainstream languages and programming environments;
forcing people to install and learn a new package manager (instead of
just giving them the option to do so) is additional culture-shock that
can be avoided.
Tim.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
