Use session's start_directory in session creation

[minijackson]

This will make tmux's whole session be in a given directory, instead of just changing windows and panes' relative paths

[codecov-io]

Current coverage is 83.91% (diff: 100%)

Merging #197 into master will increase coverage by 0.08%

@@             master       #197   diff @@
==========================================
  Files             5          5          
  Lines           742        746     +4   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            622        626     +4   
  Misses          120        120          
  Partials          0          0          

Powered by Codecov. Last update df60657...613622d

[tony]

This is breaking tests on tmux 1.8.

Maybe it can be a conditional support on the tmux version?

[minijackson]

Done!
But there seems to be a problem with libtmux's is_version function when tmux's version is 1.9a (probably a parsing problem)

[tony]

Rebased against df60657

[tony]

@minijackson can you make tests for this?

[minijackson]

Sure thing

[minijackson]

Unfortunately, I can't find a way to get the working directory of a session (even with tmux commands). I could inspect the process to see it's cwd, but that doesn't seem to be the right solution to me…

[minijackson]

The session's environment doesn't have the right PWD, so I'm guessing that even inspecting the process is a no-go

[tony]

Sorry for the late response, I am having issues keeping up with the project. I'm seeking maintainers @ #290. If you (or someone you know) may be interested in helping maintain libtmux or tmuxp, feel free to contact me by email or in the #290 issue.

In the mean time, if you're still interested in this PR, can you rebase it via git pull --rebase origin master?

[tony]

@minijackson Can you rebase this?

I just merged #623 which moves us to a poetry packaging setup and will runs the PR through GitHub actions.

Also, air traffic control, is this the same as #403?

[minijackson]

@tony Yes this is an implementation of the same feature as #403, with the check that Tmux is not 1.8. I'll rebase the PR in a quick moment.

[minijackson]

Done!

[tony]

@minijackson Thank you! Is it possible you could check out the linting issue?

@anddam I just had an issue with you being let out of a PR at #441. In this case it seems @minijackson had this before you, but do you have any comments on this approach vs your own?

[codecov]

Codecov Report

Merging #197 into master will decrease coverage by 0.13%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #197      +/-   ##
==========================================
- Coverage   77.08%   76.95%   -0.14%     
==========================================
  Files           6        6              
  Lines         829      833       +4     
  Branches      238      239       +1     
==========================================
+ Hits          639      641       +2     
- Misses        131      132       +1     
- Partials       59       60       +1     

Impacted Files	Coverage Δ
tmuxp/workspacebuilder.py	87.57% <50.00%> (-0.92%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bdb2154...52fcceb. Read the comment docs.

[minijackson]

Lint should pass now ^^

[minijackson]

Oh, I cannot find the is_version function in libtmux anymore...

[minijackson]

There we go! It simply was renamed to has_version

[tony]

@minijackson That leads me to a more questions, since if I publish, this goes to a lot of users that already have a bit of using tmuxp without this

If I could - I'd just have had this have been the default behavior. My concern is atm people are relying on this and triggering automated stuff. I'm wondering if we should add this - but feature flag it somehow so users aren't caught with a new behavior off guard

Would this change behavior / disrupt any users using the current behavior as it is on master as of now? (e.g. what if they're relying on start_directory's behavior not setting stuff? e.g. they have a script executing somehow)

Is this something we should issue a deprecation warning behavior ? Have toggleable via an option? Phase it in via an env variable?

Could you write something to CHANGES explaining the behavior? Explain the behavior in the documentation?

[tony]

Also I may be overthinking it by the way - let me know what you think 😊

[minijackson]

I think you're right that this changes could break some setup for end user: if a launched script creates a new window or pane dynamically for example. This may be a quite specific usecase, but not impossible to imagine. Breaking this usecase could be avoided by adding a new option (like session_directory) instead of using the start_directory.

I don't think this is optimal, since that means the behavior of the session's start_directory and the window's start_directory are incoherent: new panes are created under the window's start_directory, but new windows would not be created under the session's start_directory. But this is the current behaviour and users are used to it.

I'm afraid the choice isn't clear cut, and I don't think it is mine to make, but either way I'm happy to use a different option name, and update the doc if you want.

[tony]

@minijackson I propose you document this in CHANGES and docs, and we merge this

I think I will then release this in 1.6.0, rather than a bug/patch-level release. To be super safe. Rationale:

• If someone was doing a serious command it'd be done manually
• If someone was doing something very niche, it'd be through tmux itself
• This behavioral change comparable to tmux(1)'s version bumps
• If someone was doing commands that'd break stuff, they shouldn't update feature releases
• The effects of this are really minor, they only effect newly created windows in a session, and they're matching the behavior normal tmux users would expect

[minijackson]

@tony That's fine with me! I'll see if I can document that tomorrow.

[tony]

@minijackson Sounds good!

[minijackson]

@tony I'v updated the CHANGES file, but I'm not sure if or where I should update the documentation

[anddam]

@anddam […] do you have any comments on this approach vs your own?

He actually managed the 1.8 case I was asking about in my PR.

[joseph-flinn]

@minijackson I am unsure of what the original problem was here, but it seems like this may be solving the case of new windows/panes (from tmux vs tmuxp) being created in the original directory where tmuxp was run. If this is the case, a bug hotfix was just released last weekend that fixes this problem (v1.5.8+).

[minijackson]

Yes, looking at the diff of #639, it seems that this PR is now a duplicate. Thank you for telling me!