For any kind of technical related query regarding system hard drive, check
[https://uaetechnician.ae/acer-laptop-hard-disk-replacement](https://uaetechnician.ae/acer-laptop-hard-disk-replacement)
for the best solution. Hope this will help you.
> It would be cool if nimble install X just installed stuff in the current
> folder's 'lib/pkgs/deps' directory and updated/created .nimble to reflect the
> installed dependancies and their versions
It would be much better if nimble could recognize two different dependency lib
that depend on
I love vendoring. I will vote for vendoring. I think some thing like this would
be cool:
It would be cool if nimble install X just installed stuff in the current
folder's 'lib/pkgs/deps' directory and updated/created .nimble to reflect the
installed dependancies and their versions.
Its
**@dom96** The idea is that any release zip of source code would contain the
vendor libraries. Most of the time you wouldn't check them in.
The NuGet package manager for .net does something similar (as does nom), in
that packages for a project are local to the project, and stored in a
> Often times they don't even have a project. Creating a .nimble file just to
> play around with a package would be tedious.
it isn't, as long as it's just a nimble init away. AFAIK
[stack](https://docs.haskellstack.org/en/stable/README/) and other modern build
tools work this way and they're
Speaking of which, it's useful to track what dependencies (and exact versions)
were used in a build and ship this information with the binary.
This can be used to automatically identify if a binary was built against
libraries affected by known vulnerabilities or that use obsolete protocol/file
**@euant**
> In addition to what you've mentioned, Nimble also really could do with having
> the ability to vendor packages within a package/application rather than
> always relying on a global package store.
It seems that a lot of people really want vendoring. But to me it just seems
like a
**@andrea**
> For some reason, though, I often see libraries that recommend to do nimble
> install to make them available.
I believe the reason this recommendation is so widespread is that developers
very often prefer to test out packages before adopting them into their project.
Often times
I thought it would be a nice idea to create a better nimble readme:
[https://github.com/yglukhov/better-nimble-doc/blob/master/README.md](https://github.com/yglukhov/better-nimble-doc/blob/master/README.md)
The basic idea is to define the readme as if better nimble already existed.
How would
When creating a software project, it is important that it is reproducible. This
means that the dependencies for that project are not, for instance, globally
installed on the developer machine, but there is an automated way to retrieve
them and make it available.
Many language-specific package
10 matches
Mail list logo
