I am trying to have a local copy of current code base of mgo.v2. https://gopkg.in/mgo.v2 says to install using go get gopkg.in/mgo.v2. I forked it from https://github.com/go-mgo/mgo/tree/v2 and trying to install it from go get forked repo from git but it changes the package structure(changes from /src/gopkg.in --> /src/github.com) and it fails saying
src/github.com/eateshk/mgo.v2/error.go:4: "ERROR: the correct import path is gopkg.in/mgo.v2 ... " evaluated but not used
I understand the error, but what's the solution for this ?
This is a common problem when forking go packages. Canonical or "vanity" imports require the code to live in the specified path or they won't compile. The only solution is to remove the // import "gopkg.in/whatever" comment that exists somewhere.
There are other problems with your approach as well. imports within their repository will resolve back to the original repo and cause all kinds of confusion unless you rewrite them.
Rather, I suggest an alternate approach. The only place this can live on disk without causing problems is $GOPATH/src/gopkg.in/mgo.v2. Anything else will cause problems. So:
go get gopkg.in/mgo.v2
cd $GOPATH/src/gopkg.in/mgo.v2
git remote add mine your_git_fork
Now you can pull upstream changes from origin and push your changes to mine. It feels a bit odd, but it really is the only way to work from a fork without causing tons of extra pain by rewriting things.
Related
Relatively new to Go and wondering if there's any way to start a new project using a dependency you've already called go get or go mod tidy for in a previous project, without being connected to the internet?
Is there any way to import a whole package without having to reconnect to the internet to download/tidy further subpackages from the same dependency?
Reason I ask is that I don't normally have internet access where I code, so it becomes quite annoying to faff about to get things off the ground.
So far the only thing that seems to work is copying the old project and clearing it out, but that seems kind of ridiculous, even without having to specifically remove things you don't want to use again from the mod/sum files. Surely I'm missing something?
My $GOPATH points to ~/go
The package(s) I hope to use are in $GOPATH/pkg/mod. Would it be too egregious to place pkg/mod on the $GOPATH?
Thanks for any help you can give!
You can use vendoring. Run
go mod vendor
This will create a "vendor" directory and the go tool will use the dependencies from there.
See https://golang.org/ref/mod#go-mod-vendor fore more information.
I'm writing a MIDI parser that splits apart MIDI files and adjusts the volume on different tracks to allow for specific voice isolation to help practicing. I'm using a Go library, EasyMIDI. However, I ran into a use case that the library didn't cover, so I forked the repo and made changes that should fix my issues in the short term.
I'm able to successfully build when using my forked Github URL in my go.mod and import statements, but the code changes I made aren't being reflected. I added the function GetChannel() to an interface, and so should see it listed as an option. When I click into the source for another function that was originally implemented, I see that my VSCode is referencing the non-forked repo when grabbing the code (see screen snippet below).
As you can see on the left, there is no GetChannel() function. If I click on "algo!guy" and select "!try431", I do see the changes I made and pushed to my fork. How do I get my code to recognize that I want my forked repo so I can get access to these changes I've made?
Edit: Thought I might as well throw in the go.mod and go.sum files that are generated upon a go build.
go.mod
module github.com/Try431/acc-midi-splitter
go 1.12
require github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087
go.sum
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087 h1:dXDwjgIHMgL4zow9ixgTslZ3cWZHHIu3+FurDjDC6wA=
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087/go.mod h1:c/dd/WkUR9yfzjC9sPO9J0vh5TzTmE8ryAvEviTDwgg=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399 h1:f0h3xTKQjrTzAUwqMJr1TY3lk3gTK8R4v7ZjcSMiwm8=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399/go.mod h1:z6svyEeOasADFxg4gn6funK2OBjocr62B4J7ZPodCPs=
I've tried deleting the algoGuy lines in the go.sum, but obviously the lines are put back on a go build.
You can use a replace statement in go.mod:
replace original => fork
This should make references to the original repo in the forked source lookup from the forked repo.
I am using Circle CI to test my project. The project is a simple Go application consisting of a few packages and a main.go file. When referencing packages within my project I simply import them as "projectName/packageName" in the code. This works fine locally, however, when I push to git and it gets built on Circle CI I get the following errors.
package crypto-compare-go/handlers: unrecognized import path
"crypto-compare-go/handlers" (import path does not begin with
hostname)
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Has anyone had this problem with Circle CI before?
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Nope. You get this wrong. Your go will use the local $GOPATH/src/github.com/myGitUsername/projectName dir to compile. You access github.com only if you run go get -u <package path>. It is documented in How to Write Go Code.
Note that you don't need to publish your code to a remote repository
before you can build it. It's just a good habit to organize your code
as if you will publish it someday. In practice you can choose any
arbitrary path name, as long as it is unique to the standard library
and greater Go ecosystem.
I am working on a Laravel project and it's working fine. But
Recently I have updated Composer by composer update and Composer updated successfully.
Then I have removed unnecessary packges from the vendor folder. I have also removed paragonie folder from vendor, which is unwanted for me.
This gave me following error.
Fatal error: require(): Failed opening required '/var/www/laravel/vendor/paragonie/random_compat/lib/random.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/laravel/vendor/composer/autoload_real.php on line 54`
I have added this folder and working fine.
Any one can help me to figure out what is purpose of paragonie folder.
Why it is included?
Composer manages every package inside the vendor/ folder. You simply can't remove any folder from vendor/ without breaking something. Don't do this!
If you want to remove packages from your project then edit your composer.json and perform a composer install.
There might be some packages in your vendor folder that are not required from your composer.json. This is because ever package can have it's own requirements. If you delete one of these required packages you break it.
There is generally NO necessity to remove anything from vendor!
Note: composer update does NOT update Composer itself. It updates every package of your project! To update Composer itself use composer self-update.
I really recommend you to read the composer docs or some tutorial on how composer works for a better understanding of composer.
Don't manually edit composer.json, or the file-structure of the vendors folder. The vendors folder contains the dependencies and their dependencies.
The most important part about this is that you should not EVER edit a project dependency within a project. The second you do, you have broken future updates, This is a terrible thing.
If you feel this is not possible because a library needs changes, I'd suggest taking a breath.
Most libraries have some built-in configuration options, or methods of modifying the library. If they don't then maybe contribute some, or fork the library.
You can absolutely make changes to any library that has a permissive license towards source code modifications, that is why open-source code exists, but you need to do this in the right way.
You can possibly improve the code by forking using source control, which will also allow you to submit a pull-request(PR) to the package maintainers.
The benefit of trying this is that IF the package maintainers decide to accept your changes, you will be up-to-date with all of their future updates, even if you do not have time to maintain your changes, someone will probably pick them up and make their changes.
IF your PR is not accepted; I would strongly consider revisiting your initial assumptions so that you can be sure the decisions you are making are the only way, or the most beneficial way forward. Either way; it won't matter, as you can keep your fork as the version you pull from in future and either add it to packagist (only if you are really more people will benefit from it); or telling composer to pull directly from your repository (it does have to be on the internet AFAIK).
If you have to fork, you will need to ensure you can maintain the dependency, and this is accepted within your organisation. If it's you then in future, you can manually update from time-to-time from the original source library; to ensure you still enjoy the benefits of the core library, whilst keeping your changes.
THIS IS THE DIFFERENCE BETWEEN HIGH-SCHOOL CODING AND PROFESSIONAL DEVELOPMENT.
sorry for shouting / exclaiming, but this needs to be put out there more, possibly in 100ft letters somewhere.
Resolving this problem folowing these steps:
go to your project from terminal (CLI)
cd vendor
svn add paragonie
svn commit -m ""
And if another file is missing do the same thing.
For me it works 100%.
Good luck.
I have a class, which is part of a code library project that was written for a particular purpose that is no longer required. So the question is what do you do with code like this? Do you simply delete it, or do you leave it in bearing in mind that future developers may come across it and not realise that they can disregard it or do you have some sort of archive system, is there a recognised "pattern" that is in use...
Delete it. You can always get it back from the version control system later. You do have version control, don't you?
As Neil said, delete it. If I'm hired to maintain your project years after you are done with it and it's still full of dead code.. I'm gonna haunt you. And not the ooooohhhhh nice kinda haunting.. but the ARRRRWWWGGGGGRRRR!!!!! annoying kind of haunting.
It depends.
If it is unused because it is obsolete, I would clean it from the current code base by deleting it. If it turns out that it is in fact needed, you can always retrieve it from source control.
If it is unused at the moment, but may be used in the near future, I would keep it in the current code base as I wouldn't expect fellow developers to browse the source control for features just in case. In other words: if you delete something that has a high chance of being used, chances are that someone will re-implement it.
If it is not used anywhere, and no longer required you should delete it to avoid confusion.
You didn't say what code you are using but in C#/VisualStudio you can use the Obsolete attribute to tell other developers not to use the code, you can set the errors argument to true, and this will break the build anywhere that the code is being used.
I would start off by tagging the out-dated code elements with the Obsolete attribute. That way you will be able to locate any code that refers to the out-dated elements, giving you a way to update those parts. When you no longer get any compiler warnings that you use obsoleted code, go ahead and delete it.
Update: OK, now I was thinking .NET and C#, but I am sure many other languages have similar features...
I try to keep my application code as little as possible. Library code should be compatible for a number of release then remove it or just mark it as deprecated.
I totally agree with Neil. Use SVN or any other version control system to keep track of your code and delete anything that is redundant. Too much commented code only makes your code hard to read, and in some cases debugging impossible.
The best option is to remove the code so you have a cleaner repository. Most of the time it is just a short term fealing you delete somehting of potential enormous value.
Counting on svn if fellow programmer need it later won't really work. Because you have to know the code existed before and then some has to scan through the svn.
If I really think I want to keep that code than I usually make an archive out of the files and add them with a description into our wiki and then I delete the code. Over the search of the wiki someone can find the code. Scan it using the archive and as the decription contains repository and revision number they can even ressurect the parts they need easily.
If it's much, reusable and/or code difficult to reproduce, I usually put it into a file called <projectname>_rubbish.<ext>. Not very elegant but I can easily ignore it and also look for it seamlessly when I do need it again.
Install GIT then:
cd <code repo>
git init .
git add .
git commit -m 'inital import for my old code'
... Refactor the code ...
git add <path/to/file/with/changes/>
git commit -m 'that feels much better... :)'
... Create an account on GitHub or setup a GitServer
git remote add origin <remote git repo>
git push origin master
And you're done... :)
Simply delete it. If it is no longer required, there is no point in keeping it.