# Packages all should use, all the time (at least be aware of), to combine in one superpackage: Julia2.jl

**URL:** <https://discourse.julialang.org/t/packages-all-should-use-all-the-time-at-least-be-aware-of-to-combine-in-one-superpackage-julia2-jl/80300>\
**Category:** General Usage\
**Created:** [April 30, 2022, 4:56pm UTC](https://discourse.julialang.org/t/packages-all-should-use-all-the-time-at-least-be-aware-of-to-combine-in-one-superpackage-julia2-jl/80300 "2022-04-30T16:56:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [April 30, 2022, 4:56pm UTC](https://discourse.julialang.org/t/packages-all-should-use-all-the-time-at-least-be-aware-of-to-combine-in-one-superpackage-julia2-jl/80300/1 "2022-04-30T16:56:32Z")

</div>

I’m thinking of a curated list of packages, that (almost) all can agree on, to bring up to syntax-parity with e.g. Python (which has e.g. pattern matching), and so new users do not have to discover these packages for themselves. I’m not thinking of packages, such as Revise.jl, here, only helping development, but those for all to use at runtime, even hopefully in short-running scripts.

I’m ok with the package having some breaking changes, i.e. from the Julia 2.0 milestone. I’m thinking it would imply similar to Python’s `from __future__ import`, for all the stuff all can agree on anyway, thus an opt-in way to prepare for Julia 2.0 (the package would work identically in 1.x and 2.x).

Alternatively, the package could be a simple meta-package, only containing one long `using` statment, not adding (or dropping) 2.0 stuff, or messing with the included packages.

It’s likely a requirement the packages be at 1.0+, so e.g. DataStructures.jl is out (also not clear it should be on the list, anyway). I feel however justified that OrderedCollections.jl should be there for OrderedDict (Python’s, by now, default for their dictionaries).

This idea is sparked by e.g. most recently announced:

> **[GitHub - fredrikekre/EnumX.jl: This is what I wish \`Base.@enum\` was.](https://github.com/fredrikekre/EnumX.jl)**
>
> This is what I wish \`Base.@enum\` was. Contribute to fredrikekre/EnumX.jl development by creating an account on GitHub.

@fredrikekre With it a drop-in replacement for `@enum` and better, people shouldn’t have to search for alternative (or missing) “syntax”, already there in Julia. I don’t really know it that package could have overridden `@enum` in Base with its implementation. Even though that package doesn’t, Julia2.jl could. I’m not a huge fan of Julia codebases having inconsistencies, some using `@enumx` or other alternatives that exist, to stuff already in Julia (my exception is for `Dict`, but about semantics, not syntax).

For some reason the code is shorter at 165 lines than the code in Base at 225 lines: [https://github.com/JuliaLang/julia/blob/master/base/Enums.jl](https://github.com/JuliaLang/julia/blob/master/base/Enums.jl)

If we can actually redefine what Base gives you then I (maybe controversially) suggest:

```julia
const Dict = OrderedDict
const UDict = Base.Dict # shorter than having to type UnorderedDict

```

My short-list of packages to include (what more?):

- Match.jl
- OrderedCollections.jl
- EnumX.jl

See also my older (most answers where on development packages, or e.g. CSV.jl that not all would use, and is too heavy to include):

> [@Is there some minimal list of packages (almost) all users should use?](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583):
>
> I do see e.g. brand new ConcreateStructs.jl but it may be too new, so I have established packages in mind at least. I’m not thinking of e.g. some statistics package, but to add language features (and well Revise.jl), not something you would already get from say an IDE. E.g. people from coming from Scala would miss pattern matching, and I know it exists (in more than one package). I also see Underscores.jl and other similar. Could I rely on the manual to document most of the default go-to packa…

Could we also remove stuff from Julia in this package?  
I’m thinking of from 2.0 milestone:  
[stop exporting HTML and Text from Base · Issue #29841 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/29841) and [deprecate \<\<, \>\>, \>\>\> on BitArray · Issue #30958 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/30958)

Even though I wish possible, some (parser) things can’t be changed(?) in a package: [Parse 1 + 2 + 3 as +(1, +(2, 3)) · Issue #34999 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/34999) and [.|\> should have lower precedence than -\> · Issue #38761 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/38761)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [May 2, 2022, 12:22pm UTC](https://discourse.julialang.org/t/packages-all-should-use-all-the-time-at-least-be-aware-of-to-combine-in-one-superpackage-julia2-jl/80300/2 "2022-05-02T12:22:03Z")

</div>

> [@Palli](#):
>
> I’m thinking it would imply similar to Python’s `from __future__ import`

I was a bit intrigued finding a stdlib module `Future` in Julia. Maybe it could handle the Julia 2.0 part of my proposal.

It has only two functions, one already deprecated (or isn’t it already?) and seems the other `randjump` (because `MersenneTwister` is no longer the default and will go away in 2.0) should be too. What is this module for, i.e. which future does it refer to? Seemingly later 1.x; and/or Julia 2.0?

> <https://github.com/JuliaLang/julia/blob/master/stdlib/Future/src/Future.jl>