3 ms·

This was the comment that most clearly explains the issue, I'd say. I think that this is an issue of properly covering a use-case, and having simple configurat

This was the comment that most clearly explains the issue, I'd say. I think that this is an issue of properly covering a use-case, and having simple configuration options to avoid manual and cumbersome steps... But I don't think this means that a build system shouldn't default to downloading its deps. Basically, if "build systems should only build" means - build systems would be better off with an offline build mode available I agree 100%... Otherwise, if it's - build systems shouldn't have an option to automatically download the dependencies and then build I'm still in disagreement

forgottenpass 10y ago
Ignoring what any particular toolset chooses to do, building software and package management can conceptually be separated. Of course they get intermixed in practice, package management provides build prerequisites, and completely separate tools are not necessarily conductive to getting information from the build system (or dependency list in the tarball) to the package manager. Or for the download/installation provided by the package manager to be at the perfect scope for the software build. I, unlike grandparent poster, am not making statements of "ought" for build systems. Just providing context. However, I can still generically say, the tightness of the build and package management limits user flexibility. I'ts not even a particularly interesting phenomenon. It's just another case of software coupling. There are benefits to high coupling and benefits to low coupling. Typically tight coupling means the normal use case works better at the cost of all abnormal use cases. It's the same-old-same-old of all software design. ---- As a side note, I will say that in my experience an inflexible or awkward to use "offline" build mode is not an offline build mode. If "offline build mode" means: -The tarball contains (or build system generates) a list of files that can just as easily be fetched with `wget -i deps.txt` and dropped into a subdirectory manually. That's cool. If it's: -I have to reverse engineer a one-off package manager architecture, write a script to fetch build-deps externally and hack the build to support my particular flavor of offline build because it's not the type of offline build envisioned by the tool author Then that's bunk.
- lmm 10y ago
  > Ignoring what any particular toolset chooses to do, building software and package management can conceptually be separated. I'm not sure they can, or at least not without creating a circular dependency. It is greatly advantageous for build steps to be first-class packages that can use the library ecosystem etc.
- snuxoll 10y ago
  Nothing is stopping you from tarring up ~/.m2 and distributing it, though most people just keep a local maven repo up instead.

forgottenpass 10y ago

Ignoring what any particular toolset chooses to do, building software and package management can conceptually be separated. Of course they get intermixed in practice, package management provides build prerequisites, and completely separate tools are not necessarily conductive to getting information from the build system (or dependency list in the tarball) to the package manager. Or for the download/installation provided by the package manager to be at the perfect scope for the software build. I, unlike grandparent poster, am not making statements of "ought" for build systems. Just providing context. However, I can still generically say, the tightness of the build and package management limits user flexibility. I'ts not even a particularly interesting phenomenon. It's just another case of software coupling. There are benefits to high coupling and benefits to low coupling. Typically tight coupling means the normal use case works better at the cost of all abnormal use cases. It's the same-old-same-old of all software design. ---- As a side note, I will say that in my experience an inflexible or awkward to use "offline" build mode is not an offline build mode. If "offline build mode" means: -The tarball contains (or build system generates) a list of files that can just as easily be fetched with `wget -i deps.txt` and dropped into a subdirectory manually. That's cool. If it's: -I have to reverse engineer a one-off package manager architecture, write a script to fetch build-deps externally and hack the build to support my particular flavor of offline build because it's not the type of offline build envisioned by the tool author Then that's bunk.

lmm 10y ago
> Ignoring what any particular toolset chooses to do, building software and package management can conceptually be separated. I'm not sure they can, or at least not without creating a circular dependency. It is greatly advantageous for build steps to be first-class packages that can use the library ecosystem etc.
snuxoll 10y ago
Nothing is stopping you from tarring up ~/.m2 and distributing it, though most people just keep a local maven repo up instead.