# Extending a Package (without forking)

**URL:** <https://discourse.julialang.org/t/extending-a-package-without-forking/73091>\
**Category:** General Usage\
**Tags:** package\
**Created:** [December 14, 2021, 7:26pm UTC](https://discourse.julialang.org/t/extending-a-package-without-forking/73091 "2021-12-14T19:26:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gideonsimpson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gideonsimpson/32/1928_2.png) [@gideonsimpson](https://discourse.julialang.org/u/gideonsimpson)\
**Post date:** [December 14, 2021, 7:26pm UTC](https://discourse.julialang.org/t/extending-a-package-without-forking/73091/1 "2021-12-14T19:26:39Z")

</div>

I have a package that I wrote which is part of the Julia package registry that I would like to extend in a nonstandard way. It’s organized in the same spirit as `Optim.jl` in the sense that there are a much of different solver methods that the user can invoke, and it makes use of multiple dispatch to use them smoothly.

For a particular problem I’m working on, I need a custom solver which is not part of the existing package, and it is far too specialized to merit including in it. I was hoping to be able to do something like:

```julia
using MyPackage
include("custom_method1.jl")

```

and then be able to use all of the interfaces associated with `MyPackage` but with my custom solver. However, this generates a type error, presumably because `MyPackage` wasn’t built with the `custom_method1.jl` file as part of its source.

Other than just forking the package, is there a way to get Julia to support such an extension?

---

<div class="post-metadata">

**Author:** ![rejuvyesh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rejuvyesh/32/91_2.png) [@rejuvyesh](https://discourse.julialang.org/u/rejuvyesh)\
**Post date:** [December 14, 2021, 10:24pm UTC](https://discourse.julialang.org/t/extending-a-package-without-forking/73091/2 "2021-12-14T22:24:10Z")

</div>

It’s hard to say without more specifics but there shouldn’t be an issue with extending a registered package. Ideally the original package defines an `abstract` type and the appropriate functions for it, so when you extend it for your use case it’s not an issue. If it doesn’t do it, one possible workaround would be to have a `convert` function that transforms your type into the types in the original package so you can reuse the methods there.