I have a tool, call it mytool, that makes use of other code in a separate package I have written - call it mypackage.
I can build and test it in LiteIDE if I use the following structure:
/src/mypackage/mypackage.go
/src/mytool/tool.go
/src/mytool/tool.yaml
but when I want to test or deploy on GAE using:
cd ... \src\
\go\gae\go_appengine\dev_appserver.py mytool/
or
\go\gae\go_appengine\appcfg.py update mytool/
I have to move stuff around to:
/src/mytool/mypackage/mypackage.go
/src/mytool/tool.go
/src/mytool/tool.yaml
Is there something I can change in LteIDE so it can handle the second structure or is there something I can change in the GAE setup to make it handle the first structure?
I am working on Windows 7.
Have you tried installing the package using go install? That creates the compiled binary in the packages directory so the rest of your packages/code can treat it the same as a 3rd-party package.
Related
I'm new to golang. I'm currently trying to use the godror driver to read from an Oracle db. I ran go get github.com/godror/godror in my project's root directory and am importing the library like so:
_ "github.com/godror/godror"
But, I'm getting the error
cannot find package "." in:
/test_repo/vendor/github.com/godror/godror"
I believe my PATH is set up properly, as the "go" command properly returns the expected "Go is a tool for managing Go source code..." response.
I can't exactly replicate your issue nor have I seen such a weird error - but regardless, if you were following the current go modules pattern you wouldn't have this issue to begin with.
You shouldn't run go get anymore to download modules to use for your programs. Instead, in the root directory of every go project, you'll run go mod init [modulename], which will create a go.mod file for you. After running go mod tidy, it will download all the dependencies and generate a go.sum file containing the dependency hashes for you as well. Next, running go build will generate a binary that you can run. At this point, if you make changes to any source file(s), running go build every subsequent time afterwards will make a new, updated binary in the same directory.
I have used VS Code as my code editor for building service using Go for almost one year. Then, I tried to switch to GoLand. But, when I tried run a test function there is an error: cannot find package "." What is the problem?
Note: I use go module as go dependency management tool. When I use dep (in another project), there is no error when running a test function. My project is in GOPATH.
Please make sure there's a valid go.mod file defined at the ROOT of your project i.e. in $GOPATH/src/<Project-name>.
If you don't have, you can create one using go mod init command using the shell. More information on the same - https://github.com/golang/go/wiki/Modules
After that please try running the test from the shell. First cd into the directory where the test file is present. Then, use go test . -test "<TestName>" -v to run your test. If the issue goes away, you can run the test from IDE and it should work fine.
Routing doesn't work at all for me in bee if I use modules while GOPATH old approach works perfectly.
I am new in golang, correct me if I did something wrong.
I have been trying to create API project with bee, but I found that all new projects have to use the modules approach released in go 1.11.
I used bee api api-name command to scaffold the new project. It appeared in GOPATH. I moved out it from GOPATH path to another directory. Then I did go mod init mod, then I was able to run bee run and API was successfully started but routing didn't work. I did some comparing and found out that commentsRouter file wasn't generated.
What am I do wrong?
I tried to do set GO111MODULE=on and then go get -u github.com/beego/bee but this wasn't helped as well.
Now I can't even run bee API, I see
0004 Failed to build the application: main.go:4:2: package api-name/routers is not in GOROOT (c:\go\src\api-name\routers)
What's happens? I am confused. Official go documentation says that I should prefer modules approach with new projects but I can't find somewhere in docs anything about how to scaffold and use bee with modules system.
Just because missing file commentsRouter_controllers.go. Don't know how beego does not generate file routers/commentsRouter_controllers.go when running app outside $gopath.
Then we can only access to localhost/swagger. Any another path (or route) is all 404 returned.
Solution:
Not a good way but worked:
copy source code of $your_project to $gopath/src
cd $gopath/src/$your_project > bee run (just for generating file commentsRouter_controllers.go) > stop running app
copy file $gopath/src/$your_project/routers/commentsRouter_controllers.go to $your_project/routers
cd $your_project > bee run
Good luck
It looks like latest Beego Bee supports generating routes outside the GOPATH.
Have a check. It did work for me now.
I've developed a python script for building a bunch of dependencies that I need for my project. Among them is Poco.
On OS X and Linux I'm using cmake to build Poco and my first thought was to do the same for Windows. It seems, however, that the cmake pipeline isn't supported on Windows (or I'm doing something wrong) which leads me to my question; how do I go about building Poco for windows from the commandline?
For Windows you will find preconfigured scrips for building POCO using specific VS compiler version i.e. build_vs120.cmd or generic one buildwin.cmd which you can configure according to what you need:
C:\dev\workspace\poco-1.6.0>buildwin.cmd
Usage:
------
buildwin VS_VERSION [ACTION] [LINKMODE] [CONFIGURATION] [PLATFORM] [SAMPLES] [TESTS] [TOOL]
VS_VERSION: "90|100|110|120"
ACTION: "build|rebuild|clean"
LINKMODE: "static_mt|static_md|shared|all"
CONFIGURATION: "release|debug|both"
PLATFORM: "Win32|x64|WinCE|WEC2013"
SAMPLES: "samples|nosamples"
TESTS: "tests|notests"
TOOL: "devenv|vcexpress|wdexpress|msbuild"
Default is build all.
NOTE: You may need to download sources for Windows
Edit: There doesn't seem to be an install equivalent on Windows for when using the build batch script. In order to mimic linux install, one needs to merge all include folders into one, so basically copy include folders from Foundation, JSON, Net, Util, XML, and so on into one location by overwriting them. All folders except Foundation which is a Poco core namespace have structure: {Name}/include/Poco/{Name}, i.e. Util/include/Poco/Util so they will merge without any problem. As a result one should get the following structure: include/Poco/* This should be easy to scriptize too.
My app uses Mochiweb.
I have noticed that Mochiweb files reside in the myapp/deps/mochiweb directory and rebar compiles them when I run make in the myapp directory.
I wanted to add ibrowse to write a few tests which make http requests to my app. So I cloned ibrowse from github to myapp/deps/ibrowse directory.
But it seems that Erlang does not know where to get the .beam files for ibrowse and therefore all my tests that use the ibrowse module fail:
myapp
ebin %%compiled tests reside here, tests which use ibrowse fail (badarg)
deps
mochiweb
ibrowse
ebin %%compiled ibrowse module resides here
src
tests
How can I make my Mochiweb-based app use other Erlang/OTP external libraries?
Should I edit rebar.config or Makefile for that? Or maybe I should edit an _app.src file?
Edit: Maybe I should edit the list of directories in the myapp_sup.erl file? (myapp_deps:local_path(["priv", "www"])
P.S. How does my app know where all the mochiweb.beam files reside? (for example, the generic myapp_web.erl uses a call to mochiweb_http module, but there is no mochiweb_http.beam in the myapp/ebin directory).
Dependencies in rebar are added via the rebar.config file:
%% What dependencies we have, dependencies can be of 3 forms, an application
%% name as an atom, eg. mochiweb, a name and a version (from the .app file), or
%% an application name, a version and the SCM details on how to fetch it (SCM
%% type, location and revision). Rebar currently supports git, hg, bzr and svn.
{deps, [application_name,
{application_name, "1.0.*"},
{application_name, "1.0.*",
{git, "git://github.com/basho/rebar.git", {branch, "master"}}}]}.
Then, you probably want to look at Erlang releases and release handling with rebar. Think to a release as a way of grouping applications.
http://www.erlang.org/doc/design_principles/release_handling.html
http://learnyousomeerlang.com/release-is-the-word
https://github.com/basho/rebar/wiki/Release-handling
Adding the following code to myapp_web.erl solved my problem:
ibrowse:start()
By default Mochiweb is started in the same function:
mochiweb_http:start()...
I am not sure if it the proper way to do this, but it works.