Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize the working directory configuration #173

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
3 participants
@yeswolf
Copy link

yeswolf commented Oct 11, 2018

  • One can launch the application from the .build or other folders even from the command-line, not necessarily from the Xcode
  • #if Xcode requires each IDE to use the same preprocessor definition as Xcode does and that's not good since we need to introduce another entity for the particular run configuration in the particular IDE.

Initially created here

@vzsg

This comment has been minimized.

Copy link
Member

vzsg commented Oct 11, 2018

This PR is missing an important point in the original function – in particular, the reason of the #if Xcode check – and will break existing workflows in the de facto most important IDE: Xcode.

In a freshly generated Xcode project, the Run scheme uses a temporary folder in DerivedData as the current working directory by default. getcwd will return this folder as well, and from it, there is no way do find the project directory again – which is pretty important for file serving, template rendering, etc.

While the developer can manually set the project folder as a custom working directory, there is no way to override this when running tests in Xcode.

Other IDEs don't have to define the Xcode flag, they just have to use the project folder as the working directory.


If the project is not run in Xcode, getcwd will have absolute precedence (as the other code path is not even compiled in), and the app just works.


Adding extra logic for .build and Packages in the current path seem pretty arbitrary and not realistic – normally you would not touch these folders manually in a develop-run-repeat cycle.

@tanner0101

This comment has been minimized.

Copy link
Member

tanner0101 commented Oct 16, 2018

You can run the app from the proper working directory even if it is in the .build folder. Just do:

.build/debug/Run

If you are using something like Supervisor, there are options to set the working directory.

In Vapor 2 there was a flag you could pass to set the working directory used. We could consider porting this to 3, but unless there's a reason why the previous two solutions wouldn't work it's probably not worth the effort.

@yeswolf

This comment has been minimized.

Copy link
Author

yeswolf commented Nov 6, 2018

I got the logic and even though just removing the #if Xcode problem solves the problem when developing the application, it's incorrect when we run the app on the server. Closing this pull request and hoping that some solution like used in Kitura (that does not rely on the IDE) will be implemented.

@yeswolf yeswolf closed this Nov 6, 2018

@tanner0101

This comment has been minimized.

Copy link
Member

tanner0101 commented Nov 6, 2018

Closing this pull request and hoping that some solution like used in Kitura (that does not rely on the IDE) will be implemented.

@yeswolf do you have a link to the implementation you are referencing? I'd be interested to look at it.

@vzsg

This comment has been minimized.

Copy link
Member

vzsg commented Nov 7, 2018

Fun fact about Kitura's FileKit module: you can inude it in your Vapor project and use it instead of DirectoryConfig if it suits your needs better. You could even wrap it in a custom DirectoryConfig.

Without actually knowing what the problem is (you haven't shared anything about your magical IDE or how you deploy to your server, just that something doesn't work), it's pretty hard to come up with a solution that works for all of us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.