dateutil vs. python-dateutil

[Skip Montanaro]

I was just comparing packages between one of my environments and one
created by a colleague. I have python-dateutil 2.6.0-0 installed. He
has dateutil 2.4.1-0. I think these represent potentially conflicting
versions of the same package and shouldn't both be available.

I'm looking at a local cache at work, but see both package names
available on my laptop as well, which looks out on the net wherever
these packages exist. Is Conda in some sort of transition period where
both are available?

Skip Montanaro

[Chris Barker]

On Thu, May 4, 2017 at 9:58 AM, Skip Montanaro <skip.mo...@gmail.com> wrote:

I was just comparing packages between one of my environments and one
created by a colleague. I have python-dateutil 2.6.0-0 installed. He
has dateutil 2.4.1-0. I think these represent potentially conflicting
versions of the same package and shouldn't both be available.

have you confirmed that they do, in fact, provide the same python package? I agree it's likely.

Anyway,  in the default channel, there appears to be "dateutil" from version 1.5 to 1.4.1

Then there is "python-dateutil" which goes from version 1.4.1 to 2.6.0

(and conda forge also has python-dateutil versions 2.4.1 - 2.6.0)

So it looks like it was renamed, and "python-dateutil" is the one to use now.

hopefully other packages that depend on it have made the shift.

This is part of conda's growing pains -- there was (and still isn't, really) a clear policy on when to prefix a package with "py-" or "python-" or "lib'" or ...

But you are right -- if someone does a conda install dateutil after installing python--dateutil, they could accidentally downgrade :-(

I have no idea about the policy of removing packages from defaults -- but it seem that would break older environment files, so probably better not to.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Skip Montanaro]

> have you confirmed that they do, in fact, provide the same python package? I
> agree it's likely.

Yes, I checked in a couple ways. One, I manually downloaded the latest
of both packages and extracted the tar files. They seemed to be mostly
the same. (I've been using dateutil for years and do recall a change
in package name in the wild as well).

Then I checked it empirically. I already had python-dateutil
installed. I then installed and removed dateutil. After that, I could
no longer import dateutil from Python code. I then removed and
reinstalled python-dateutil and was back in business.

I'm not very Conda-package-savvy. Does it provide some way to identify
conflicts between packages of different names or indicate renames?
Wandering down a different rabbit hole today, I tried installing
"binstar", which conda informed me is now "anaconda-client". I don't
know if that's special, or if there is a general "this was renamed"
mechanism.

Skip

[Kale Franz]

I believe they're the same package.  I believe the conda package was originally just named dateutil, and at some point Ilan migrrated the name of the conda package to match what's on PyPI.  That package, for whatever reason, really is called python-dateutil on PyPI.  One of the most used of all packages on PyPI--the name seems redundant to me too.

Anyway all of the conda dateutil packages should be fairly old and not updated any longer.

--
You received this message because you are subscribed to the Google Groups "conda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conda+un...@continuum.io.
To post to this group, send email to co...@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/conda/.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/conda/CANc-5UyjaCXyfdZqPvPf%3DD37y6XN3Eg%3DN5bJL5MUw-OCjRt_DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

--

Kale J. Franz, PhD

Conda Tech Lead

kfr...@continuum.io

@kalefranz

221 W 6th St | Suite 1550 | Austin, TX 78701

[Chris Barker]

On Thu, May 4, 2017 at 2:35 PM, Skip Montanaro <skip.mo...@gmail.com> wrote:

> have you confirmed that they do, in fact, provide the same python package? I
> agree it's likely.

Yes, I checked in a couple ways.

that's that then.

 

Then I checked it empirically. I already had python-dateutil
installed. I then installed and removed dateutil. After that, I could
no longer import dateutil from Python code. I then removed and
reinstalled python-dateutil and was back in business.

so there is room for this to be broken, but it's getting old, so hopefully not too many ou tof date dependencies or instructions out there.

 

Does it provide some way to identify
conflicts between packages of different names or indicate renames?
Wandering down a different rabbit hole today, I tried installing
"binstar", which conda informed me is now "anaconda-client". I don't
know if that's special, or if there is a general "this was renamed"
mechanism.

I think that's a special case, as it's a core tool from continuum very closely tied to conda.

However, it would be good if there was some ay to check (or ideally an install-time warning) that a package was going to overwrite something that's already installed. I think it's assumed that conda packages will al lply well together, but as the ecosystem expands that may not be robust enough.

-CHB

[Kale Franz]

Then I checked it empirically. I already had python-dateutil
installed. I then installed and removed dateutil. After that, I could
no longer import dateutil from Python code. I then removed and
reinstalled python-dateutil and was back in business.

Yup.  What happened was that conda clobbered all of the dateutil package's files/paths when you installed python-dateutil, but dateutil still thought it had ownership of those paths, so removing dateutil wiped out the python-dateutil files.

However, it would be good if there was some ay to check (or ideally an install-time warning) that a package was going to overwrite something that's already installed. I think it's assumed that conda packages will al lply well together, but as the ecosystem expands that may not be robust enough.

There is!  In conda 4.3.

`conda config --set path_conflict warn` or `conda config --set path_conflict prevent`  The current default is 'clobber'.  In early versions of conda 4.3, the default was 'prevent', but we had way too many conflicts within packages.  We're working on building a tool to scan a full channel and check for path conflicts among packages, so we can clean up the packages before we switch the default values on users and inflict a lot of pain.  We have a few problems in repo.continuum.io, but we're planning on making this tool more widely available.  Just because it's a more distributed group of people working on conda-forge, I'm guessing conda-forge is going to have a lot more overlaps.

--

You received this message because you are subscribed to the Google Groups "conda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conda+un...@continuum.io.
To post to this group, send email to co...@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/conda/.

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/conda/CALGmxELhUtV70A%3Dk5zXWxQSPcLLft3US5bFJT5X94Aihypz-dA%40mail.gmail.com.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.