`dependencies` vs `dev-dependencies`

[dry pumice]

Is there an explainer somewhere about the differences between dependencies and dev-dependencies?

This is what the gleam.toml docs say:

# The Hex packages the project needs to compile and run (optional)
# Uses the Hex version requirement format
# https://hexdocs.pm/elixir/Version.html#module-requirements
[dependencies]
gleam_stdlib = "~> 0.18"
gleam_erlang = "~> 0.2"
gleam_http = "~> 2.1"

# The Hex packages the project needs for the tests (optional)
# These will not be included if the package is published to Hex.
# This table cannot include any packages that are already found in the
# `dependencies` table.
[dev-dependencies]
gleeunit = "~> 0.3"
gleam_bitwise = "~> 0.3"

[gleaming venture]

I think dependencies are pulled when the lib is used as a dependency

[queen pike]

pretty much what the docs there say, dev dependencies are dependencies people need to pull in to develop your package. dependencies are things needed to pull in to use your package

[gleaming venture]

while dev dependencies are only used if it is the main app

[queen pike]

[dev-dependencies]
gleeunit = "~> 0.3"

clearly gleeunit is just for the unit tests, so theres no point getting users of our package to download gleeunit because they wont be running our package's unit tests

[dry pumice]

To help contextualize things further, I'm primarily asking in regards to glenvy (https://discord.com/channels/768594524158427167/1112901322740600963) where I currently instruct users to install it as a dev dependency.

But based on the usage it would still get called when running in production, so I just want to make sure it's not going to cause someone's app to blow up if they add it as a dev dependency and then deploy.

But it sounds like for applications the distinction between the two doesn't really matter

[uneven spruce]

i wouldnt considering if i want to use it in an application i'd need it as a regular dep

[queen pike]

for applications there is no practical distinction between dev and non-dev deps

but if someone publishes a package that uses glenvy, and they've included glenvy as a dev dep, things will break because glenvy wont be installed when someone installs that package

[uneven spruce]

better to not be prescriptive and let people import things as whatever kind they want

things like testing, benchmarking, etc etc, things you don't need to actually use the lib as a dep are what i usually stick as dev deps