Incorrect output directory paths

[monomadic]

I have a relatively simple setup, and I'm using the latest codekit (2.8, but also happened on 2.7x). This bug could simply be a UX bug, as it's very easy to reproduce so I would think it would have been caught by now unless I'm misunderstanding something fundamental.

Since I'm wanting to generate output for github pages, I need index.html in my root directory, but which to have my src in a ./src directory, like so:

I configure sass files globally as follows:

In the sass preference window for an individual sass file, it shows the path as such: Which seems to include the absolute path including /Users/ - which would be fine except that it creates that exact folder structure inside the project root:

I've spent a while on this now, trying various options, and it really does seem that codekit is either fundamentally broken (on my machine? maybe my environment is misconfigured somehow?) or there's some not-so-obvious configuration option I haven't found yet.

Has anyone else encountered this?

[bdkjones]

Are you on OS X Yosemite or El Capitan?

[monomadic]

El Cap 10.11.5

[bdkjones]

Hmm. Interesting. This was an issue around CodeKit 2.4 because of a fundamental bug in OS X's filesystem caching mechanism. However, I haven't had a report of it in a long time. I'm wondering if it might be because you've got a blank (empty) "relative to" path that you're adding to the project root folder.

Does the issue manifest if you supply an actual relative path in that text field?

[monomadic]

Tried changing almost everything there, have put in manual names, it just appends them.

[bdkjones]

Hmm. Okay, the first thing to try is a fresh start. Take the project in question and duplicate the whole project folder. Let the duplicate folder be named ‘X’ in this example. In X, delete the codekit.config file. Then, put X in your Sites folder. Add it to CodeKit. Does the path issue persist? If so, repeat this process with another complete duplicate (Y), but this time put Y on your Desktop instead of in your Sites folder. (The Sites folder was one that was commonly corrupted by this OS X caching bug.)

On 14 Jun 2016, at 23:56, Rob Saunders notifications@github.com wrote:

Tried changing almost everything there, have put in manual names, it just appends them.

https://cloud.githubusercontent.com/assets/129359/16070606/470784cc-3309-11e6-9d3f-a16901a0e518.png https://cloud.githubusercontent.com/assets/129359/16070608/4a6ec90e-3309-11e6-904e-99938b786e65.png https://cloud.githubusercontent.com/assets/129359/16070620/58070f36-3309-11e6-801a-f4be5ea1682c.png — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bdkjones/CodeKit/issues/619#issuecomment-226103847, or mute the thread https://github.com/notifications/unsubscribe/AA4jZilsfS27E8Cc1kE2n6Biy6IAwwIBks5qL6IlgaJpZM4I2CsV.

[monomadic]

I deleted all traces of the codekit project and started again. Same issue. Whenever I switch it to use the 'project root directory' (with everything else as totally untouched and default), it sticks in the full path, after the project root. For what it's worth, I'm using slim and sass - maybe there's something wrong with (one of) those interpreters.

Here's another thing. If I try something like this:

It says it renders just fine in the log, but no file is even output! Just fails silently.

I've tried other things, like ./ or . or ./build or ../build or leaving the field blank. It just refuses to work in any form with project root.

I can't see why it should affect the Sites folder and not others, and I use many many dev tools (and write my own) and none of them are affected by this issue, it's just a directory call. But just to try it, I created a fresh project inside my home directory, same issue.

I think, if I'm stuck this early in with such a simple issue, codekit is too buggy for me, I don't really trust it. My trial is almost up anyway and I couldn't get through its bugs in that time.

[monomadic]

Guess what... I worked it out. Certain folder names don't work. I had a root project folder name (following a naming convention I have been using for a while) of this:

robsaunders.io-codekit

When renaming to just robsaunders, worked. It's the .io part that breaks it, as periods in the name break it. MacOSX sometimes recognises these as packages then, but it shouldn't affect codekit... weird bug.

This bug could easily come into play with github pages, as you are forced to name the repository the name of your github domain, eg. robsaunders.github.io in my case - so if I check out the default directory, it won't work in codekit.

[bdkjones]

Yea. Periods in folder names are a bad idea perpetrated on developers by script-kiddie hipsters too drunk on ridiculously overpriced craft beer to know any better.

[dlewand691]

I'm having a similar issue with files that have been renamed after they've been compiled and don't maintain the new name. I opened an issue a couple days ago about it.

[monomadic]

They're a valid directory name, and necessary in some situations (like here, github forces you to put the url as your repo name). Not to mention that unix uses periods in filenames for various reasons and the macOS layer on top does too.. what if, for whatever reason, someone wanted to deploy a codekit project in a bundle? Or you, for whatever reason, have it in a hidden directory? Or, far more commonly, you name your directories after the website you are making? Apple has a common convention of periods in filenames (look at any xcode project, or a quick look in your ~/Library, for example). If you don't want to support that as a developer, fine, but alert the user about it instead of failing obtusely. Regardless, there are common use cases where a user might use periods in file names.

Since we're apparently throwing insults around, I could say that knowingly not supporting valid directory names in your application, and silently failing instead of gracefully advising the user of the problem, is a bad idea perpetrated by developers who don't QA properly :P

[bdkjones]

Ha, you could. But it's not me. It's Apple's APIs for dealing with the filesystem. Many of them take for granted that the text after a period is an extension, so when they see a directory name with a period in it, they go haywire. In places where this problem crops up, I've had to write a lot of extra code to handle poor naming choices. All of these issues should be resolved in 3.x, which is due out soon.

Sent from my iPhone

On Jun 24, 2016, at 00:02, Rob Saunders notifications@github.com wrote:

They're a valid directory name, and necessary in some situations (like here, github forces you to do so).

I could say that not supporting valid directory names in your application is a bad idea perpetrated by developers who don't QA properly :P

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.