Am 04.01.2015 um 20:38 schrieb Aaron Meurer:
I think you're right. The proglems I know of with pip are
- packages that have bad metadata in setup.py (something we can easily
avoid)
Or at least fix because it's a bug :-)
- combinations of packages that have some version restrictions.
That's unavoidable.
In the Java world, people work around this by renaming modules.
I.e. if module A requires library com.fubar.biglib and module B requires
the same but at a different version, integrators include two copies of
com.fubar.biglib, but one version renamed (e.g. com.fubar.A.biglib).
The catch is that all code in A now needs to refer to com.fubar.A.biglib.
Similar things could be done in Python.
The failure mode here is when class names are constructed from strings,
because the renaming pass does not find all occurrences of
com.fubar.biglib in A. But actually that's just the same problem as with
Java, and probably no more often than in Java.
> I doubt
people will want anything but the latest mpmath. The only issue might be if
mpmath breaks compatibility in some subtle way that breaks an old version
of SymPy, and someone needs to use an old version of SymPy. In that case,
they will need to know what version of mpmath to install in addition to
SymPy. Conda does help here because in addition to having a true dependency
solver, it lets you add dependency restrictions to old versions of packages
retroactively. But honestly, with mpmath, it's a non-issue, and I doubt it
will come up in any serious way.
Well, even seemingly nonserious problems can cause trouble.
OTOH if somebody needs to keep some old combo of software alive, they're
going to freeze it anyway.
I'm more concerned about people who use SymPy together with some other
software. They might end using a version of mpmath that's incompatible
with either current SymPy or that other software.
(by the way, in case you didn't know, I work on conda for my day job, so
I'm very biased in that direction)
Well, from a packaging point of view, all packaging software uses the
same format for describing dependencies. I.e. if everybody uses
requirements.txt, it's easiest to set something up that will work for
all users, regardless of what packaging software they use.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/54A9B368.7030004%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
