# A type from the same library passed via different paths is not considered identical

**URL:** <https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528>\
**Category:** General Usage\
**Created:** [December 20, 2019, 9:05pm UTC](https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528 "2019-12-20T21:05:26Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fjarri](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fjarri/32/630_2.png) [@fjarri](https://discourse.julialang.org/u/fjarri)\
**Post date:** [December 20, 2019, 9:05pm UTC](https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528/1 "2019-12-20T21:05:27Z")

</div>

I’ve encountered a strange situation while setting up CI for one of my projects. I have a package [LogProof](https://github.com/nucypher/LogProof.jl) that uses another package, [DarkIntegers](https://github.com/nucypher/DarkIntegers.jl). `DarkIntegers` is in the Julia registry, `LogProof` isn’t.

`LogProof` tests [fail for julia-1.0 in CI](https://app.circleci.com/jobs/github/nucypher/LogProof.jl/5), while the same tests for 1.2 and 1.3 pass. The reason, essentially, is the following:

- a `DarkIntegers.Polynomial` object is created by a function in `LogProof`
- a function from `DarkIntegers` is called with this object in the test script
- despite the function having a method specialized on the type `Polynomial`, the call fails

The fail is buried in the broadcasting machinery, but if one just calls some straightforward function from `DarkIntegers` acting on `Polynomial` objects, the result is the same - a method fails to be resolved.

This _only_ happens if one uses a `Polynomial` object created by a function in `LogProof`; an object created in the test itself works fine. This only happens in Julia 1.0 (both in CI and on my local machine), not in 1.2 or 1.3. It doesn’t seem to happen in my other analogous projects which also use `DarkIntegers`. I thought that maybe I specified dependencies incorrectly, so `LogProof` uses a different copy of `DarkIntegers` as compared to the test script, but then it wouldn’t happen in CI, would it?

So, does anyone have any ideas about how to diagnose this?

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [December 20, 2019, 10:55pm UTC](https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528/2 "2019-12-20T22:55:24Z")

</div>

Are you loading the same files with include multiple times? That can cause two separate copies of all of the same functions and types to be created which don’t know about each other.

---

<div class="post-metadata">

**Author:** ![fjarri](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fjarri/32/630_2.png) [@fjarri](https://discourse.julialang.org/u/fjarri)\
**Post date:** [December 20, 2019, 11:34pm UTC](https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528/3 "2019-12-20T23:34:40Z")

</div>

Nope, pretty sure I don’t. The file with the type in question is included once inside `DarkIntegers.jl`, and then `DarkIntegers` is connected via `using` in the test script.

---

<div class="post-metadata">

**Author:** ![fjarri](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fjarri/32/630_2.png) [@fjarri](https://discourse.julialang.org/u/fjarri)\
**Post date:** [December 21, 2019, 4:05am UTC](https://discourse.julialang.org/t/a-type-from-the-same-library-passed-via-different-paths-is-not-considered-identical/32528/4 "2019-12-21T04:05:23Z")

</div>

Huh, I did some more digging and apparently the fail in CI was caused by a different issue after all; the problem on my local machine was solved by clearing out the environment and reinstalling everything (not sure what was causing it exactly). Sorry for the confusion.