# Can I remove dependency on Pkg from my package using xxx\_jll?

**URL:** <https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704>\
**Category:** General Usage\
**Created:** [March 28, 2023, 9:57am UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704 "2023-03-28T09:57:00Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jsjie/32/22477_2.png) [@jsjie](https://discourse.julialang.org/u/jsjie)\
**Post date:** [March 28, 2023, 9:57am UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/1 "2023-03-28T09:57:00Z")

</div>

For some reason, I want to compile my package into binaries with `PackageCompiler`. It generally works fine, but compiled directories always include something like `libgit2`, which should be of no use to my package.  
After some digging, I find the main reason to be the dependency on `Pkg`, which comes from many `xxx_jll` packages.

Let’s first have a look at how many dependencies `Pkg` with introduce:

```julia
[[deps.Pkg]]
deps = ["Artifacts", "Dates", "Downloads", "LibGit2", "Libdl", "Logging", "Markdown", "Printf", "REPL", "Random", "SHA", "Serialization", "TOML", "Tar", "UUIDs", "p7zip_jll"]
uuid = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f"

```

It can be understood that seems I want to compile my package into binaries to deliver, dependencies like `Downloads` (which then depends on `LibCURL`), `LibGit2`, `REPL`, `p7zip_jll` and so on are generally useless.  
Besides, these dependencies will introduce vulnerabilities, like I have reported last year in [this post](https://discourse.julialang.org/t/vulnerabilities-in-binary-executables-especially-for-windows-platform/90688). `LibCURL` and `LibGit2` will both introduce vulnerabilities, like [CVE-2021-22945](https://nvd.nist.gov/vuln/detail/CVE-2021-22945), [CVE-2018-25032](https://nvd.nist.gov/vuln/detail/cve-2018-25032), and so on. Yes, the latter is a zlib bug, but libgit2 depends on that. These vulnerabilities sometimes can be solved by simply remove the related files, but why we ever have them, when we don’t need them at all?

Then, the reason for this.  
It seems that these packages are created by `JLLWrappers`, (through `Yggdrasil`, I suppose?) and are relevant with following codes:

```julia
macro generate_main_file_header(src_name)
    return excat(
        # Declare this module as interpreted
        generate_compiler_options(src_name),
        # import Artifacts module
        generate_imports(src_name),
    )
end

```

```julia
macro generate_main_file(src_name, pkg_uuid)
    return excat(
        # `is_available()` forward declaration, `PATH_list` and `LIBPATH_list` forward definitions,
        # `find_artifact_dir()` definition.
        generate_toplevel_definitions(src_name, __source__ ),
        # Select and load the best wrapper file
        generate_wrapper_load(src_name, pkg_uuid, __source__ ),
    )
end

```

Digging further, I find the following:

```julia
function generate_imports(src_name)
    # We lie a bit in the registry that JLL packages are usable on Julia 1.0-1.2.
    # This is to allow packages that might want to support Julia 1.0 to get the
    # benefits of a JLL package on 1.3 (requiring them to declare a dependence on
    # the JLL package in their Project.toml) but engage in heroic hacks to do
    # something other than actually use a JLL package on 1.0-1.2. By allowing
    # this package to be installed (but not loaded) on 1.0-1.2, we enable users
    # to avoid splitting their package versions into pre-1.3 and post-1.3 branches
    # if they are willing to engage in the kinds of hoop-jumping they might need
    # to in order to install binaries in a JLL-compatible way on 1.0-1.2. One
    # example of this hoop-jumping being to express a dependency on this JLL
    # package, then import it within a `VERSION >= v"1.3"` conditional, and use
    # the deprecated `build.jl` mechanism to download the binaries through e.g.
    # `BinaryProvider.jl`. This should work well for the simplest packages, and
    # require greater and greater heroics for more and more complex packages.
    @static if VERSION < v"1.3.0-rc4"
        return quote
            error("Unable to use $($(src_name))_jll on Julia versions older than 1.3!")
        end
    elseif VERSION < v"1.6.0-DEV"
        # Use slow Pkg-based Artifacts
        return quote
            using Libdl, Pkg, Pkg.BinaryPlatforms, Pkg.Artifacts
            using Pkg.Artifacts: load_artifacts_toml, unpack_platform
            using Pkg.BinaryPlatforms: triplet, select_platform
            HostPlatform() = platform_key_abi()
        end
    else
        # Use fast stdlib-based Artifacts + Preferences
        return quote
            using Libdl, Artifacts, JLLWrappers.Preferences, Base.BinaryPlatforms
            using Artifacts: load_artifacts_toml, unpack_platform
            using Base.BinaryPlatforms: triplet, select_platform
        end
    end
end

```

Thus, `Pkg` seems to be required for pre-1.6.0 versions only? However, because of the considerations of backward compatibility, we will always have `Pkg` as a dependency, at least before we move to julia 2.x?

Besides, some `xxx_jll` packages need `LazyArtifacts`, which in turn depends on `Pkg`. This also is of no meaning for compiled binaries, I suppose?

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [March 28, 2023, 3:29pm UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/2 "2023-03-28T15:29:15Z")

</div>

Is there a way to define conditional dependencies (say, for julia\<1.6), like in Python? I tried to check but couldn’t find anything.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 29, 2023, 7:26am UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/3 "2023-03-29T07:26:16Z")

</div>

> <https://github.com/JuliaPackaging/BinaryBuilder.jl/pull/1261>

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [March 29, 2023, 5:33pm UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/4 "2023-03-29T17:33:57Z")

</div>

Neat! So after this patch has been released, and probably after the jlls in question have been regenerated with that new version, we can expect smaller packagecompiler results? 😀

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 29, 2023, 5:48pm UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/5 "2023-03-29T17:48:55Z")

</div>

Yes. Note that this is _already_ in use in [Yggdrasil](https://github.com/JuliaPackaging/Yggdrasil/), so you only need to wait for more and more packages to be updated.

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [March 30, 2023, 8:36am UTC](https://discourse.julialang.org/t/can-i-remove-dependency-on-pkg-from-my-package-using-xxx-jll/96704/6 "2023-03-30T08:36:58Z")

</div>

I just tried updating one of my projects, and indeed I could observe that some jll Manifest entries lost their Pkg dependency, nice!  
I went from ~85 to 81 instances of this, so there is still a ways to go. 😅