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

$HOME not considered as a "dev" root #3

Open
pnu opened this issue Mar 25, 2014 · 2 comments
Open

$HOME not considered as a "dev" root #3

pnu opened this issue Mar 25, 2014 · 2 comments

Comments

@pnu
Copy link

pnu commented Mar 25, 2014

On Heroku, applications are deployed to path /app. This path contains the project root of a Catalyst app, for example. The application tries to find the share directory from the project root. (this is a DBIx::Class::Migration (ping @jjn1056) script that uses File::ShareDir::ProjectDistDir, that uses Path::FindDev to do the job.)

However, on Heroku /app is also user's $HOME. Finding share fails, because according to Path::IsDev default heuristics, $HOME can never be a "dev" directory. When traversing up from the application's lib-directory, the search skips over the /app, so /app/share is never considered.

The "positive" heuristics would match (and do, on my local dev env), but IsDev doesn't even consider those after the negative HomeDir match. Maybe this makes sense on some environments, but at least on Heroku this assumption is not correct.

(I can manually override the path in the db migration script, but using the ProjectDistDir is considered the community best practice, and ignoring the /app feels just arbitrary in this case.)

I'm not sure if/how this should be fixed, so I don't have a PR or any other concrete suggestions here. Just pointing out the issue with it. Could you just remove the HomeDir heuristics from the default set, or what is the reasoning behind it?

I think there can be many cases, where user's home really is the "dev" root of some module or app. For example, if I run tests as a dedicated user and checkout the project (to be tested) on that user's $HOME.

@kentfredric
Copy link
Member

There's an alternative approach if you can afford to tweak %ENV

https://metacpan.org/pod/Path::IsDev::HeuristicSet::FromConfig

I think there can be many cases, where user's home really is the "dev" root of some module or app. For example, if I run tests as a dedicated user and checkout the project (to be tested) on that user's $HOME.

Sure, this may be the case, but its not so far the dominant case.

The rationale was mostly that it kept false positiving because users had a t/ directory in $HOME or .git or similar.

I personally don't consider ProjectDistDir much of a "Best practice", its a useful tool for certain cases ( which I concede Catalyst apps are one ), but wherever possible, use Test::File::ShareDir::* instead. ( Much more reliable and no side effects at installtime )

Yeah, such is the nature of heuristics though. They'll never be perfect, just percentages of acceptable behaviour if you work in ways they're targeted for.

@kentfredric
Copy link
Member

It will probably be better once I put some harder limits on where FindDev can uplevel.

Much of these heuristics are safe-guards against accidentally marking $HOME/perl5lib/* or $HOME/perl5/perlbrew/* descendants as "development" directories.

Because presently, the uplevel heuristic doesn't consider itself "production" until there is a path between itself and $FSROOT free from positive matching.

Fixing that won't make it perfect, but it should make it more flexible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants