Comments (16)
pip and npm are probably widely used enough to warrant some investigation. unfortunately, i'm not one of those who would use this and don't install either of these package types globally. when talking about a per repository basis, there are already good options so i'd question what the goal of this would be and where homebrew-bundle would do a better job than the existing options.
from homebrew-bundle.
Perhaps I'm misunderstanding, but 'the existing options' are like
- nix-darwin
system 'npm install -g ...'
in brew bundle- manually/user's own script
? There isn't really a good way for a homebrew/bundle user to do it.
from homebrew-bundle.
npm has package.json
and pip has requirements.txt
for this sort of thing. bundle doesn't have this capability today but i personally don't see where it fits in the ecosystem against the existing options.
from homebrew-bundle.
Homebrew treats its Python as a runtime dependency for Python apps, not something for the end user to use directly. This, despite common usage in this way, is perilous because a new Python version can break existing base-level package installations and virtual environments alike. I reckon NPM works the same way, although I have very little experience with it.
The problem with installing packages from pip and npm like this is apparent then: Which Python or Node installation should they be installed against? That uncertainty seems to really complicate the expression of intent manifest in the Brewfile.
Something worth thinking a little more about for the Python side of this is pipx
. Homebrew's pipx
formula seems to have some thought about Python version changes, so it might be unaffected by the aforementioned problem.
from homebrew-bundle.
npm has
package.json
and pip hasrequirements.txt
for this sort of thing. bundle doesn't have this capability today but i personally don't see where it fits in the ecosystem against the existing options.
This. If we wanted to do this it would be less "list all npm
modules in Brewfile
" and more "have a DSL for the Brewfile
that runs e.g. npm install
.
Homebrew treats its Python as a runtime dependency for Python apps, not something for the end user to use directly. This, despite common usage in this way, is perilous because a new Python version can break existing base-level package installations and virtual environments alike. I reckon NPM works the same way, although I have very little experience with it.
@colindean This isn't correct, sorry; please hold off giving this advice to folks, thanks ❤️
good options so i'd question what the goal of this would be and where homebrew-bundle would do a better job than the existing options.
This is the primary question that would need answered here.
Which Python or Node installation should they be installed against? That uncertainty seems to really complicate the expression of intent manifest in the Brewfile.
This is fairly easy to solve given Homebrew's existing integration with peenv
and nodenv
.
from homebrew-bundle.
package.json & requirements.txt are a good point, unlike Brewfiles they're not typically used for system packages so it just didn't cross my mind.
But then we still run into the issue of the system python being installed by brew as 'externally managed', so it can't be installed to without --break-system-packages
. It seems weird to me to do that but not then provide a mechanism for installing to it - even those formulae that exist (e.g. python-requests
) are deprecated as don't do that.
On Arch for example pacman installs python similarly, but then also packages python-* (and nodejs-*) libs for installing them.
If I want (for example) requests
available system-wide, what am I supposed to do? Have some 'system' venv somewhere that I activate in every shell and pretend?
from homebrew-bundle.
package.json & requirements.txt are a good point, unlike Brewfiles they're not typically used for system packages so it just didn't cross my mind.
System-wide installation of NodeJS/Python libraries does not play nicely with Homebrew so we don't recommend it really.
It seems weird to me to do that but not then provide a mechanism for installing to it
That's because you're not meant to: you're meant to install to e.g. a virtualenv or the Python modules for your user.
If I want (for example)
requests
available system-wide, what am I supposed to do?
Not do that.
Have some 'system' venv somewhere that I activate in every shell and pretend?
That or install this library as the user(s) running the shell(s).
from homebrew-bundle.
Is there a single other package manager that behaves like this, on any platform? You can do what you want obviously, I'm just saying it's surprising behaviour.
That or install this library as the user(s) running the shell(s).
I'm not sure what that means, just to call the venv I described $(whoami)
instead of 'system'? Sure, but that's just a filename, that doesn't change anything.
from homebrew-bundle.
Is there a single other package manager that behaves like this, on any platform?
Bundler, for example, tends to default to making everything project specific rather than system-wide.
Homebrew Bundle is heavily influenced by that. I'm the primary maintainer/contributor by a pretty long way and it is strongly influenced by my opinions and experience on how best to use package managers.
With Homebrew itself: the vast majority of other package managers on other platforms require you to do sudo whatever install
and Homebrew does not. Because we don't have the root
/sudo
boundary to cross, we do things a bit differently.
Regardless: even if every package manager were to do it differently: that does not compel us to do it their way.
I'm not sure what that means, just to call the venv I described
$(whoami)
instead of 'system'?
I've never intestinally created a virtualenv so: no idea.
I have installed lots of NPM modules/RubyGems in projects and Python, Ruby, Perl modules just as my current user under e.g. $HOME/.gem
, $HOME/.pip
, though. Installing things systemwide is to be avoided when possible.
from homebrew-bundle.
I have installed lots of NPM modules/RubyGems in projects and Python, Ruby, Perl modules just as my current user under e.g.
$HOME/.gem
,$HOME/.pip
, though. Installing things systemwide is to be avoided when possible.
I can't speak to Ruby and to a lesser degree Python (I'm basically inclined to agree with you for Python), but this is not completely accurate for NPM. Some tools are designed (or at least supported) to be installed globally with NPM. Serve by Vercel is one example of the top of my head I use in this way. I think NPM should be supported as an installer type.
My main concern would be how to manage actually getting NPM installed in the first place as there are a number of ways. I'm currently trialing PNPM for example to install Node/NPM. Many use nvm/n/volta. I'd recommend leaving that to the user though to ensure npm is available on the system (probably installed by Homebrew anyway)
from homebrew-bundle.
Some tools are designed (or at least supported) to be installed globally with NPM.
They may be supported/designed that way but, speaking from experience, it's definitely not the optimal way to use said tools with Homebrew itself.
from homebrew-bundle.
So surely Homebrew is the place for a solution to what is a Homebrew problem?
Have some extra managed environment for non-dependency packages, or one per package (also solving conflicts between formulae's depenencies which presumably already has the same issue?) or whatever.
from homebrew-bundle.
They may be supported/designed that way but, speaking from experience, it's definitely not the optimal way to use said tools with Homebrew itself.
Can you elaborate for my understanding please? Are you referring to Homebrew wouldn't have the ability to install to a Homebrew specific bin directory? If so, that is something I hadn't considered. That would require setting up a mechanism like how pnpm manages packages which would be tedious
from homebrew-bundle.
So surely Homebrew is the place for a solution to what is a Homebrew problem?
I disagree this is a Homebrew-specific problem. It will apply to any package manager where there's a systemwide or user-based installation path.
Can you elaborate for my understanding please?
If you can avoid it (e.g. by installing in the relevant project or user directory): not installing things into brew --prefix
will avoid potential issues on upgrades, uninstalls, etc.
Some tools are designed (or at least supported) to be installed globally with NPM.
Also worth noting: unlike pure libraries: Homebrew already packages many of these tools e.g. https://formulae.brew.sh/formula/tailwindcss
from homebrew-bundle.
If you can avoid it (e.g. by installing in the relevant project or user directory): not installing things into brew --prefix will avoid potential issues on upgrades, uninstalls, etc.
I'm still not sure I understand. Why would using Brewfile to install an NPM module mean it needs to be installed to brew --prefix?
Also worth noting: unlike pure libraries: Homebrew already packages many of these tools e.g.
It sure does. Here is a list of some of the ones that are not pure libraries and are not packaged as formulas from my bootstrap file though:
pnpm i -g @softwaretechnik/dbml-renderer
pnpm i -g stegcloak
pnpm i -g serve
pnpm i -g surge
pnpm i -g vercel@latest
pnpm i -g @shopify/cli
pnpm i -g netlify-cli
It would be great to include these in the brewfile. They're the only things not managed by brewfile now.
from homebrew-bundle.
I'm still not sure I understand. Why would using Brewfile to install an NPM module mean it needs to be installed to brew --prefix?
That's the global NPM installation location for an NPM installed with Homebrew.
Here is a list of some of the ones that are not pure libraries and are not packaged as formulas from my bootstrap file though
It's probably worth creating formulae for some of these, either for your own use or for submitting to homebrew/core.
from homebrew-bundle.
Related Issues (20)
- Add SetApp support HOT 2
- VSCode extensions that have capital letters seem to not be registered, and get uninstalled HOT 2
- Feature request: Auto-start a cask after installation HOT 11
- Filtering installed software by a set of groups HOT 2
- Specify Package Installed from Source HOT 2
- Maintaining Ruby 2.6 compatibility HOT 4
- Qs on merging Brewfiles. HOT 2
- [Feature] Support groups HOT 1
- Error: cannot load such file -- abstract_command HOT 2
- Collection of potential new Installers/Checkers/Dumpers HOT 12
- Vscode : Case sensitive issue is back HOT 6
- [Question] Can formula and cask have the same name? HOT 4
- brew bundle dump spawns many ruby processes HOT 12
- Unattended install of a bundle HOT 4
- how to install only on specified macOS version or arch of OS HOT 1
- brew bundle [install] --cleanup removes dependencies when reading from stdin HOT 4
- Confusion on what should be dumped HOT 1
- VSCode@Insiders Support for Extensions HOT 6
- Error: private method `system' called for module Homebrew HOT 9
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 homebrew-bundle.