Coming from Ruby where I can have as many versions of every gem as I want, it's confusing to me why there is the restriction of Cabal being able to only have one version installed at the same time?
I've tried searching for an answer, but couldn't find anything explaining the reasoning behind this. And another good question would be if is there a workaround to this other than using sandboxes, which require me to recompile everything for every project (or share the sandbox, which doesn't always work).
edit: To clarify this question, what I don't understand is how cabal gets to the point where it says that installing a package would break another package. What is the cause of this issue?
I know it can be fixed by using a sandbox, but that's not an answer to the cause of this problem.
Your assumption is incorrect: cabal does allow installation of multiple versions of the same package. Packages are distinguished by version number.
Related
At work we're using a very old template (generated around April 2021, so node v14.19) which has an out of sync package-lock.json. This means that if you do:
rm package-lock.json && npm install
The install will fail due to conflicting dependencies.
For a couple of weeks me and my teammates tried to fix this, but we haven't succeed yet: when you fix the dependencies you break eslint, when you fix eslint you break deployment, when you fix deployment then the logger will stop working and so on. We have thousands of dependencies that are turning out to be an hell to maintain.
The pov of our CTO is that we simply shouldn't delete the package-lock.json, but this means we can't update node and we are stick with what I think is a huge technical risk.
Do you think it's fixable? Have you ever been in a similar situation?
Is not deleting the package-lock.json enough to avoid the problem?
If not, how could I produce an example where I can break the flow? maybe by installing a modern package that is incompatible with the old resolution?
This is one of the reasons why both modular code and teams are important. Chunking the code up to one big file or just a few files will cause this kind of mess.
Do you think it's fixable? Have you ever been in a similar situation?
Yes
Is not deleting the package-lock.json enough to avoid the problem?
No. As said in the comments, it is a big security risk not to keep your dependencies up to date. That's why you have package managers like npm. Plus, new vulnerabilities are openly discussed in different forums, so not only are scrupulous elements aware of them, good intentioned programmers are aware of them and will definitely judge your software to be of low quality. Also, you put your clients at a big risk of running into trouble with your software and put your company at risk of facing litigations.
If not, how could I produce an example where I can break the flow? maybe by installing a modern package that is incompatible with the old resolution?
My Suggested Solution:
Leave the code as is (Good thing it is still working even with new input data).
Modularize the code. Put chunks of related functionalities into separate files and import them into the main code (make sure everything is still working).
Assign teams to the seperate files (modules) to build new versions of the code (there also have to be modular testing implemented here so you can test each module independent of the main file).
For each test unit, make sure they have their own up-to-date package.json file.
Integrate everything into a new project software.
One advantage of doing things this way is that the main file code rarely changes. Also, each module can be updated independent of the main program and other modules. Only downside to this approach is that you have to manage the package.json file intentionally so that dependecies do not conflict or are not recursive during integration, thereby (sometimes) requiring a seperate team to manage integration.
Many Cygwin's packages have no maintainer, is it still revelant to use Cygwin ?
I would like to update ruby or ansible package to the last version, how can I do that ?
Thanks
Package maintainers are volunteers.
Anyone can offer him/herself for the job.
Documentation
https://cygwin.com/packaging-contributors-guide.html
Mailing list for discussion about Maintainers
https://cygwin.com/mailman/listinfo/cygwin-apps
If you want to be a maintainer you must subscribe to the Cygwin mailing lists. All discussions about maintaining packages are there, and you will be required to post your credentials (i.e. public key) there in order to upload updated packages. Note that some orphan packages became so because the previous maintainer needed to reduce their workload.
Once you are subscribed, just ask to take over an orphaned package, upload your credentials, install the source package, make necessary changes, and upload the new package. It sounds easy, but you might want to build the package and make sure it runs all tests before asking to be the new maintainer.
Note that there may be others who have tried to update a package, and encountered blocking problems. Those will be discussed in the mailing lists, which you can search.
I've created a nimble library package as per the documentation. When I try to build it using nimble build I get the following error.
Error: Nothing to build. Did you specify a module to build using the bin key in your .nimble file?
I can do this and it does fix the error but according to the documentation adding the bin key to the .nimble file turns my package into a binary package.
Other things I have tried:
Use nimble install: This does not appear to verify that my code will actually compile and will happily install anything to the local package directory (I added a C# class to my .nim file, for example, and it was successfully installed).
Use nimble c: This works but I have to pass in the path to the nim file I want to compile and the binDir entry in the .nimble file is ignored resulting in the output being placed in the same directory as the file being built. This complicates the development cycle because I have to manually clean up after the compiler.
Use the compiler directly. This is pretty much the same as the previous option with the same flaws.
I guess I could also create a separate .nim file and import my library after it is installed but this is a big overhead for just wanting to verify that a package in the early stages of development will actually compile.
I just want to be able to verify that the source code in my library package is syntactically correct and will compile. How is this meant to be done for library packages?
From your provided link to the nimble package manager documentation I have the feeling that
https://github.com/nim-lang/nimble#tests
is what you are looking for. But I have never used the test command, so I am not sure. I do my test manually still, I read the nimble docs maybe 4 years ago and can not really remember. And currently there is much package manager related work going on, I heard there is a new, alternative package manager called nimph, and from a forum thread I think I read something that nimble is going to change and improve also. Maybe you should consider subscribing to the Nim forum, that is the place where the bright Nim devs are. Well, at least a few of them.
Not sure SO is the best place to ask this, but it is development related so maybe someone can help.
I've written an app (in python but that's not important) which parses a Yum repo database to collate RPM packages and their dependencies. The problem I have is that I am sucking in too many packages when a dependency is met by more than one.
Specific example: I am seeking the list of packages which meet dependencies for Java-1.8.0 and getting a dependency of libjli.so()(64bit). libjli.so()(64bit) My code correctly works out that this is provided by multiple -devel packages from the Java 1.8, 1.7 and 1.6 streams. Unfortunately all three versions (and their dependencies) then get included in my list.
I guess my question is, given a list of packages meeting a requirement, what is the best way to identify the most appropriate package to include? i.e. when resolving the dependencies for Java-1.8.0, only include the -devel package for 1.8.0 and not suck in the -devel packages for 1.6 and 1.7 as well.
I know this is a problem with my code, I'm just not sure what facilities are provided by the yum ecosystem to help me identify which package would be best to include from the list of multiple.
It is hard to tell without seeing your code.
Yum is dead. If you are developing something new, you should develop on top of DNF. DNF use satsolver algorithm (https://doc.opensuse.org/projects/satsolver/11.4/index.html) and you can use libdnf https://github.com/rpm-software-management/libdnf (formerly known as libhif, formerly known as libhawkey).
I'm a good Java programmer, albeit the first languages I learnt were C/C++. Anyway, for work reasons, I switched to Java and web languages. Sometimes I get interested in this or that Linux project, usually coming as a git or svn repository... The problem is that I usually clone the repo, I try to configure it, I install all the needed libraries (and this takes ages), maybe finally I succeed... but then make fails or configure itself fails, complaining about some tool that is missing. Or maybe I installed two versions of the same library and the configure script gets the wrong one, or boring problems like this.
Anyway, I see loads of people using those tools everyday, so it must not be so difficult after all!
Can you point out resources that may help in the first steps?
Thanks
What you are referring to are known as autotools and make
autotools are used to generate scripts and build files that can be used to build as well as install a program/package/software (whatever you call it)
Here is wikipedia link for the GNU build system in general.
And refer to this link for details about the autotools and related stuff
It may take longer, but if you are interested in how to fix those problems yourself I recommend learning how autoconf and automake work. I made a positive experience with the book "Autotools: a practitioner's guide to Autoconf, Automake and Libtool". I read the dead-tree version but it is also available online: http://fsmsh.com/2753.