on windows

[ponzu-cms]

on windows

[nilslice]

That is close - but you need to build the project before you run it. Also, just by running go get on the project, you should have the ponzu CLI installed and available to run globally.

The steps are:

1. go get github.com/ponzu-cms/ponzu/... (gets Ponzu code and installs binary CLI)
2. ponzu new github.com/jksmithiii/mycms
3. cd $GOPATH/github.com/jksmithiii/mycms
4. ponzu build
5. ponzu run

You can use the code generator ponzu generate content [your details here] in between steps 3. and 4.

Let me know if that works for you.

Steve

[jksmithiii]

Ok, that's where I'm getting thrown off. Did a fresh get. I didn't see the binary in GOPATH/bin. I'll run back through the steps.

Thanks

[jksmithiii]

Sweet. Looks good on win 10 so far. Thanks

[nilslice]

Hi @jksmithiii -

Would you be able to paste the output from when your generate command failed, in addition to the full command you entered?

@sirikon - if you have time, maybe you can take a look at this to as the in-house Windows pro? :)

[jksmithiii]

Sure. Console output attached.

In generate.go, first fix was in setFieldView. Subsequent fix in generateContentType. The log lines printed out because I inserted a log.printLn for tracing purposes. Check error for malformed path.

[nilslice]

It looks like you are running this command from inside ponzu (the CLI), not your own ponzu project. is that accurate?

did you run this first?

$ ponzu new myProject
$ cd myProject

Where myProject is the path to your new ponzu project.

[jksmithiii]

Ok, I'm not clear on the steps then.

1. Go get ponzu
2. Build ponzu in GOPATH\src\github.com\ponzu-cms\ponzu\cmd\ponzu
3. run GOPATH\src\github.com\ponzu-cms\ponzu\cmd\ponzu\ponzu.exe new mycms
4. run GOPATH\src\mycms\cmd\ponzu\ponzu.exe gen ...

Is that correct? When does ponzu build come into play?

Thanks for help.

[sirikon]

@nilslice sorry for the delay... should be able to look at this tomorrow.

#117 (comment) Should it actually fail doing this? And doing this generation command: #117 (comment)

[nilslice]

@sirikon - no worries! I think the issue was that the CLI was being used from inside its own directory, not from a new Ponzu project.

Idk if there is an elegant way to protect it from failing (maybe just handle the error and Println a "make sure you're inside a Ponzu project" kind of message?) - but that error was not from intended use.

[sirikon]

@nilslice Ok! ^^

About the error message... a message like "Are you in a Ponzu project?" could be useful, the question is when triggering it.

Is there any way to be 100% sure that a folder is a ponzu project? Any file that is 100% required? Something inside myProject/cmd/ponzu/ ?

[nilslice]

@sirikon -

There is a way to know, since a Ponzu project will have the Ponzu source code inside the cmd/ponzu/vendor directory, whereas in the Ponzu source code itself (meaning the go get ponzu code), the source does not exist.

So the flow would be:

Are we in a Ponzu project?

• check for /cmd/ponzu/vendor/github.com/ponzu-cms/ponzu -> PASSES
  • YES
• check for /cmd/ponzu/vendor/github.com/ponzu-cms/ponzu -> FAILS
  • NO

[sirikon]

@nilslice Hmm... didn't tought that... anyway, isn't possible to have a Ponzu project with ponzu dependency in GOPATH instead of vendor?

Also, maybe this check shouldn't be blocking... for example, if I run a generate command and the check fails, will try to do it anyway, and then show the message "Are you in a Ponzu project?" if the command fails AND the check fails too.

[nilslice]

@sirikon - It is possible to have the dependency in GOPATH instead of vendor, but the CLI intentionally copies ponzu into vendor per each execution of $ ponzu new ..., since you would otherwise be forced to use the same version of ponzu for all your ponzu projects on each $ ponzu build.

The reasoning for this decision was that there could certainly be cases where users are on 0.8.x for $PROJ1, and 0.9.x for $PROJ2. If the dependency is in GOPATH for both projects, each project's internal API could break and they'd be forced to use the latest version on their system. Hence, the $ponzu [--cli] version and $ ponzu upgrade commands.

[nilslice]

Also, maybe this check shouldn't be blocking... for example, if I run a generate command and the check fails, will try to do it anyway, and then show the message "Are you in a Ponzu project?" if the command fails AND the check fails too.

That is a good point. Personally, I think we should only show the message if the command fails.. there could be other generators (like $ ponzu g addon) created later, and its possible that a generator could be used to modify the source CLI.. in all cases of the message being shown, we may want to print the current working directory so it's clear to the user that we're referring to a file system location concern.

Do you agree?

[sirikon]

@nilslice Totally agree :)

I see here two options to check:
1.- Existence of ponzu inside vendor folder
2.- Existence of the required folders for each command (If a generator creates content, then 'content' folder should exist if the folder is a valid Ponzu project

First option is more like a near-silver-bullet, but could fail when a user, because some reason, uses the ponzu inside GOPATH instead the one from vendor folder. Would agree to this if the Ponzu-inside-vendor thing is a design requirement, more than a default decision in Ponzu project generator. Otherwise, would prefer the second option

[nilslice]

Hey @sirikon -

I just realized we are missing one other scenario that is easy to catch... if pwd is $GOPATH/src/github.com/ponzu-cms/ponzu, we should block commands that move/copy/create files. There should never be a case where someone uses the ponzu-cms/ponzu repo as their own project - this is the same as someone using the rails gem as their own rails project - it just shouldn't happen.

With that, we should just print the message "Make sure you are in a Ponzu project" etc, if there are any errors from the cmd/ponzu/main() cases.

I think all that we'd need to add is some error wrapping func specific to this check..

func warnProjectLocation(err error) {
        fmt.Println(err)
        pwd, err := os.Getwd()
        if err != nil {
                fmt.Println("Failed to find current directory:", err)
                return
        }

        // check if user is running a command from inside the ponzu-cms/ponzu repo
        gopath, gopathErr := getGOPATH()
        if gopathErr != nil {
                fmt.Println("Failed to locate GOPATH environment variable:", gopathErr)
                return
        }

        ponzuCLIRepo := filepath.Join(gopath, "src", "github.com", "ponzu-cms", "ponzu")

        if pwd == ponzuCLIRepo {
                fmt.Println("Only run this command from within a Ponzu project created by the 'new' command, not the Ponzu source code.")
                return
        } 
        
        fmt.Println("Are you sure you are inside a Ponzu project?")
}

Do you think that covers it?

[sirikon]

@nilslice Looks great for me :) Just a detail: Wouldn't be better if, for comparing the file paths, we use this instead: https://golang.org/pkg/os/#SameFile ?

Comparing a filesystem path by its string representation could lead to some wrong 'false' returns. What do you think?

[nilslice]

@sirikon - I was not aware of os.SameFile, seems like a better option indeed! should take care of the non-existent path case as well.

[nilslice]

@jksmithiii - I know you're already on your way with Ponzu, but if you would like a proper introduction to the project, I have just released this video:
https://www.youtube.com/watch?v=T_1ncPoLgrg

Hope it is helpful!

[olliephillips]

Closing this issue. There's been no activity on the issue for some time. Please reopen if need to.