Comments (6)
Interaction with checked out packages
At first I thought that checked out packages were related to this, but that's actually a mostly independent matter. When you check out a package, it gets checked out in JULIA_DEVDIR
which defaults to joinpath(DEPOTS[1], "dev")
and a path to it is placed in the current environment's manifest. However, when the current environment is an old-style implicit one, there is no Manifest.toml
file to put a path into, so what does one do? I can see two options:
-
Check out the package into the implicit environment directory structure instead of in
JULIA_DEVDIR
. -
Check out the package into
JULIA_DEVDIR
as normal, but create a symlink from that location into the implicit environment directory.
I'm not sure which approach is better.
There's also the question of "What is the current environment?" I would say that the current environment should be the environment corresponding to the first entry in LOAD_PATH
that exists.
from pkg.jl.
Some questions:
- Should
LOAD_PATH
be renamed? E.g. toENV_PATH
orENVIRONMENTS
? - Or should the command-line options
--env=
and--env+
be--load-path=
and--load-path+
?
from pkg.jl.
Example usage, you might be working on a project and want to use a profiler and debugger, and so start julia
using julia --env+NamedEnv("devtools")
which would have the effect of appending the devtools
named environment to your LOAD_PATH
, thereby giving you access to any of the packages installed in there, in addition to what's in your current project's environment.
This does kind of suggest that the NamedEnv("devtools")
syntax is too verbose, so maybe we should have more concise syntaxes. Maybe --env+@devtools
? And @@
for CurrentProject()
? And !@devtools
to create the devtools
named environment if it doesn't already exist? Or maybe we don't need a syntax for that. The long syntax is fine for setting LOAD_PATH
since that tends to be done once in a config file somewhere, but the command-line really wants concise syntax.
from pkg.jl.
-
Would
LOAD_PATH
then effectively implement what is described asDEPOT_PATH
in the Julep? -
If I have projects scattered all over my home directory (eg because I keep them alongside LaTeX source and other misc stuff from coauthors relevant to a working paper, organized into directories, which may not follow the Julia package layout from their root), would it be sufficient to just make a single directory, put it in
LOAD_PATH
, and symlink in the project directories there?
from pkg.jl.
In short, no. The best description of the roles of LOAD_PATH
and DEPOT_PATH
in Pkg3 are now here: JuliaLang/julia#25709. This will obviously be properly documented before we release 1.0 final... we're still working on integration. In short, LOAD_PATH
is used to determine what packages to load while DEPOT_PATH
is used, among other things, to find installed versions of packages based on their UUID and SHA-1 git hash (also to look for registries and named environments).
from pkg.jl.
This is now implemented as of JuliaLang/julia#25455.
from pkg.jl.
Related Issues (20)
- Inconsistent preference of local directories over package names in auto hints
- `pkg> registry add https://github.com/staticfloat/General#sf/foo` does not work properly HOT 2
- Package precompilation spinners not erased before running tests HOT 3
- Source of failure in `update_registries` should be surfaced to caller HOT 2
- Allow compat specifiers in Pkg.add
- Afterimages of the download progress bar HOT 3
- restrict package by version HOT 2
- Feature request (with code!): Search for registered packages + display releases HOT 1
- Feature request: `]test --quiet` (don't always dump the whole manifest on `Pkg.test()`) HOT 3
- New HistoricalStdlibVersions version is breaking the Pkg tests HOT 1
- very unsound assumptions about REPL state injection HOT 5
- nested task error: ArgumentError: Number of elements must be nonnegative HOT 1
- Docstring for `Registry`
- Bad resolution for SHA in manager
- Improvements to registry status outputs HOT 1
- Pkg tests puts an outdated copy of `General` in `usr/share/registries`
- Dont overload `zero` for `VersionWeight`
- Hide unnecessary internal Pkg stack traces in test logs HOT 2
- `status` can error when the RHS in `[extensions]` does not map to a weak dep HOT 1
- Document two new ways of specifying test-specific dependencies
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pkg.jl.