Giter Site home page Giter Site logo

Comments (11)

rutgerbrf avatar rutgerbrf commented on May 13, 2024 4

Both rustup and ghcup install in ~/.rustup and ~/.ghcup respectively. That makes ~/.zigup seem like an intuitive location (for users which have used rustup or ghcup).

from zigup.

 avatar commented on May 13, 2024 1

Just because they do it doesn't mean zigup should. rustup even has piping a shellscript into curl straight from the internet as an installation method, which is bad practice.

Completely ignoring XDG spec for new software to me seems silly, hardcording paths is simply bad design no matter how you cut it.

from zigup.

dropwhile avatar dropwhile commented on May 13, 2024

$HOME/.local/ is a pretty common local home dir location for things these days too. As an example, it is commonly used in python land with pip install --user installing bins to $HOME/.local/bin and libs to $HOME/.local/lib.

XDG_DATA_HOME is by default $HOME/.local/share, as well.
ref: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

from zigup.

dropwhile avatar dropwhile commented on May 13, 2024

Another example: asdf-zig uses asdf and supports a "wherever it is installed" kind of thing.
note: I tossed my install in $HOME/.local/asdf, and it was working ok until I migrated to an macbook m1 -- as there is no supported zig build available on the downloads page yet for m1 macs.

from zigup.

 avatar commented on May 13, 2024

Would be nice if this respected XDG spec and put it in ~/.local instead. Polluting the home folder is generally considered a bad move.

from zigup.

g-w1 avatar g-w1 commented on May 13, 2024

I have a fork that does this.

from zigup.

rutgerbrf avatar rutgerbrf commented on May 13, 2024

Just because they do it doesn't mean zigup should. rustup even has piping a shellscript into curl straight from the internet as an installation method, which is bad practice.

Nope. However, as a user, I'm willing to do that (for once) for the added convenience.
What installation method do you prefer?

Completely ignoring XDG spec for new software to me seems silly, hardcording paths is simply bad design no matter how you cut it.

I agree. Just did some googling and came across this: rust-lang/rustup#247
ghcup has an env called GHCUP_USE_XDG_DIRS which seems a bit weird to me.
I think it would be best if zigup would use the platform's standard installation dir by default, and allow the user to customize it to whatever place they prefer.

Edit: rustup also has this issue: rust-lang/rustup#2418

from zigup.

 avatar commented on May 13, 2024

To me checking if the env vars for XDG exist first, honoring that and if they don't then checking if .local exists in the user's home folder seem to be better than just throwing everything in the home folder straight away. Barring that I guess installing in $HOME anyway is the best (only) solution.

It's a difficult choice to go back once every script or build system relies on certain stuff being available in hardcoded locations rather than checking for environment variables first. It's been a long running issue for multiple software, even Firefox (.mozilla in home) has this going on for 17 years! https://bugzilla.mozilla.org/show_bug.cgi?id=259356

from zigup.

rutgerbrf avatar rutgerbrf commented on May 13, 2024

Sounds good, there's still Windows with AppData though (seems like zigup doesn't support Windows yet anyways)

from zigup.

marler8997 avatar marler8997 commented on May 13, 2024

Now that zigup is finally working on Windows (thanks to the zarc project for extracting zip files) and we have prebuilt binaries, I thought about this issue for Windows. For Windows I'm going to go with what I originally proposed which is to install the zig.bat file that links to the actual compiler in the same directory as zigup.exe. This provides the user full control over where to install the zig.bat file because it will always get installed to the same directory as zigup.exe. To change it, the user can move zigup.exe. That being said, the directory where zig.bat goes, and the directory where zigup downloads/installs the compilers (the "install directory") don't necessarily need to be the same. To change that, the current solution would be to wrap zigup in a batch file and override the install directory via --install-dir.

Having said this, I'm thinking about removing the --path-link command-line option and always having it derived from the zigup.exe location, at least on Windows. This would mean that for the unit tests, instead of adding --path-link scratch\zig.bat to the zigup command-line, it would just copy zigup.exe to the scratch directory and call that one. I'm not sure if we want to do the same thing on linux yet, but I'll try to remember to consider it and I might go that way as well (at least for the "zig link", not for the install directory).

from zigup.

marler8997 avatar marler8997 commented on May 13, 2024

I feel like this issue has come to a resolution.

On windows the install directory is a directory named "zig" that lives in the same directory as zigup.exe. For all other platforms, it's $HOME/zig. At this point I'm happy with these being the default.

For non-default cases we can add a build option to change the default directory to something else. I'll add this if anyone indicates they would like this and this covers all the non-default cases I can think of.

from zigup.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.