This has been an issue since at least 0.10e. PyLNP can find a Dwarf Fortress folder in one of its parent directories, but it uses double the number of "../" needed to access it.
It has no problems finding and using the LNP directory when it is located in one of its parent directory.
[Issue created by jecowa: 2016-08-31]
[Last updated on bitbucket: 2016-10-09]
[Comment created by jecowa: 2016-10-09]
Not reproducible.
[Comment created by jecowa: 2016-10-09]
I'm sorry. I can't reproduce it either in 10.10. Head works fine. Old head works fine. All the old compiled versions that I can run work fine. Maybe restarting my computer fixed it?
[Comment created by Pidgeot: 2016-10-09]
I don't seem to be able to reproduce this at all on 10.8, and I don't have access to any other versions. You're just running those launch.py files directly, right?
There's a bit of code in lnp.py which takes care of setting up the working directory; my best guess is that something is happening there.
#!python
if hasattr(sys, 'frozen'):
self.bundle = self.os
os.chdir(os.path.dirname(sys.executable))
if self.bundle == 'osx':
# OS X bundles start in different directory
os.chdir('../../..')
else:
os.chdir(os.path.join(os.path.dirname(__file__), '..'))
What's supposed to happen here is:
If this is a compiled executable (i.e., packed with PyInstaller), note this and set the working directory to that of the executable.
If this is OS X, offset that to account for the way .app files work.
Otherwise, start in the directory above lnp.py (where launch.py is).
Later, in detect_basedir, it tries to find a valid DF folder (characterized by the presence of a data/init/init.txt file in that folder), starting from the current directory and gradually working its way up until it either hits the file system root, or it finds a folder.
The only situation I can think of that might cause problems is if you are compiling to a single-file executable and running that. That would indeed cause it to go up too many levels; I don't support that on OS X because this doesn't provide a way of setting an icon.
You could try running with -d and seeing if that gives any possibly relevant information in stdout.txt and stderr.txt.
[Comment created by jecowa: 2016-09-27]
Yes, the Dwarf Fortress and LNP folders were in the same directory.
I had Dwarf Fortress and LNP in directories like this:
~/hg/df_osx/
~/hg/LNP/
Then my PyLNPs were in folders something like this:
[Comment created by Pidgeot: 2016-09-27]
Just need to make sure what I'm looking for :)
The Dwarf Fortress and LNP folders need to be on the same level, but other than that they should work an arbitrary number of parent directories up. If you're doing that, and it's not working, then that is indeed something I will have to look into.
[Comment created by jecowa: 2016-09-27]
It's not a visual issue. It launches fine as long as the Dwarf Fortress directory is in the same folder as the PyLNP app. But it isn't able to launch DF if the Dwarf Fortress folder is in a parent directory of the directory that PyLNP.app is in. It can detect that the Dwarf Fortress folder there, but it can't open it. (I've only tested this stuff in Mac OS X Yosemite, by the way.)
It works fine with the "LNP" folder being in a parent directory, so I was thinking I could fix it by making it access the "Dwarf Fortress" folder like however it's accessing the LNP folder, but it's more complicated to fix than I thought.
For distributed packs, I can't think of any reason why someone would want it in a parent directory, but for testing multiple copies of PyLNP, it'd be convenient to only need one copy of Dwarf Fortress that can be used with them all. It's not a very big deal, though. It's not a big priority. Sorry if such a trivial issue wasn't worth reporting.
[Comment created by Pidgeot: 2016-09-24]
@jecowa Help me make sure I get this right: Is there something specific that's not working because of this, or is this just a visual thing? If it's the latter, then this is purely a side effect of how PyInstaller works on OS X.
[Comment created by jecowa: 2016-08-31]
I thought it seemed like something that would be easy enough for me to fix, but I don't really know what I'm doing.
[Comment created by Pidgeot: 2016-08-31]
OS X is a bit different due to how an .app file is really just a directory, so from a binary, you would expect twoextra sets of ../. It might be that those are being added in an unexpected situation or something?
[Comment created by jecowa: 2016-08-31]
Mac OS X 10.10 Yosemite
[Comment created by Pidgeot: 2016-08-31]
Which platform is this? Linux? OS X?
This has been an issue since at least 0.10e. PyLNP can find a Dwarf Fortress folder in one of its parent directories, but it uses double the number of "../" needed to access it.
It has no problems finding and using the LNP directory when it is located in one of its parent directory.
[Issue created by jecowa: 2016-08-31] [Last updated on bitbucket: 2016-10-09]
[Comment created by jecowa: 2016-10-09] Not reproducible.
[Comment created by jecowa: 2016-10-09] I'm sorry. I can't reproduce it either in 10.10. Head works fine. Old head works fine. All the old compiled versions that I can run work fine. Maybe restarting my computer fixed it?
[Comment created by Pidgeot: 2016-10-09] I don't seem to be able to reproduce this at all on 10.8, and I don't have access to any other versions. You're just running those launch.py files directly, right?
There's a bit of code in lnp.py which takes care of setting up the working directory; my best guess is that something is happening there.
What's supposed to happen here is:
Later, in detect_basedir, it tries to find a valid DF folder (characterized by the presence of a data/init/init.txt file in that folder), starting from the current directory and gradually working its way up until it either hits the file system root, or it finds a folder.
The only situation I can think of that might cause problems is if you are compiling to a single-file executable and running that. That would indeed cause it to go up too many levels; I don't support that on OS X because this doesn't provide a way of setting an icon.
You could try running with -d and seeing if that gives any possibly relevant information in stdout.txt and stderr.txt.
[Comment created by jecowa: 2016-09-27] Yes, the Dwarf Fortress and LNP folders were in the same directory.
I had Dwarf Fortress and LNP in directories like this:
~/hg/df_osx/ ~/hg/LNP/
Then my PyLNPs were in folders something like this:
~/hg/PyLNP/launch.py ~/hg/PyLNP importer fix v1/launch.py ~/hg/PyLNP importer fix v1.1/launch.py ~/hg/PyLNP importer fix v2/launch.py ~/hg/PyLNP new buttons/launch.py ~/hg/PyLNP Play DF padding/launch.py ~/hg/PyLNP v0.10e/launch.py ~/hg/PyLNP v0.11/launch.py ~/hg/PyLNP v0.12/launch.py
[Comment created by Pidgeot: 2016-09-27] Just need to make sure what I'm looking for :)
The Dwarf Fortress and LNP folders need to be on the same level, but other than that they should work an arbitrary number of parent directories up. If you're doing that, and it's not working, then that is indeed something I will have to look into.
[Comment created by jecowa: 2016-09-27] It's not a visual issue. It launches fine as long as the Dwarf Fortress directory is in the same folder as the PyLNP app. But it isn't able to launch DF if the Dwarf Fortress folder is in a parent directory of the directory that PyLNP.app is in. It can detect that the Dwarf Fortress folder there, but it can't open it. (I've only tested this stuff in Mac OS X Yosemite, by the way.)
It works fine with the "LNP" folder being in a parent directory, so I was thinking I could fix it by making it access the "Dwarf Fortress" folder like however it's accessing the LNP folder, but it's more complicated to fix than I thought.
For distributed packs, I can't think of any reason why someone would want it in a parent directory, but for testing multiple copies of PyLNP, it'd be convenient to only need one copy of Dwarf Fortress that can be used with them all. It's not a very big deal, though. It's not a big priority. Sorry if such a trivial issue wasn't worth reporting.
[Comment created by Pidgeot: 2016-09-24] @jecowa Help me make sure I get this right: Is there something specific that's not working because of this, or is this just a visual thing? If it's the latter, then this is purely a side effect of how PyInstaller works on OS X.
[Comment created by jecowa: 2016-08-31] I thought it seemed like something that would be easy enough for me to fix, but I don't really know what I'm doing.
[Comment created by Pidgeot: 2016-08-31] OS X is a bit different due to how an .app file is really just a directory, so from a binary, you would expect twoextra sets of ../. It might be that those are being added in an unexpected situation or something?
[Comment created by jecowa: 2016-08-31] Mac OS X 10.10 Yosemite
[Comment created by Pidgeot: 2016-08-31] Which platform is this? Linux? OS X?