fix ssh fsspec: make put atomic

[SebastianRiechert2]

I am facing some problems working with a ssh-remote. We are only using dvc for dataset versioning. We have little control over the remotes configuration and often when I push from local cache to remote, files arrive on remote corrupted. Multiple executions of dvc push do not fix the issue. dvc status -c does not notice the corruption on remote even though the remote contains corrupted files and the local cache intact ones. The problem is not noticed when working alone, since dvc does not detect the corruption on remote, thinks remote and local cache are in sync and dvc pull takes the files from the local cache. The problem arises when a third party tries to pull the dataset.

• When verification is turned off (in .dvc/config) dvc happily pulls the corrupted files,
• if it is turned on, dvc fetch tells me the corrupted files are getting fetched to local cache, but they actually are not, as subsequent runs of dvc status -c reveal (all corrupt files from remote appear as deleted). dvc checkout (and dvc pull) subsequently fails, I think because of the mismatch between remote and local cache.

We are using dvc repro instead of manually adding files, so fixing the problem by manually untracking and readding the files is off the table as far as I understand.

Shouldn't there be an option to check for corruption when pushing files to remote? Something like a --verify option for dvc push.

Right now, verification is only happening during pulling, at which point the corrupted files cannot be automatically fixed by re-pulling/pushing anymore. Also, the error we get when trying to pull from the corrupted remote (without intact local cache) with verification turned on is not very helpful. It just asks if the cache is up to date. The cache is up to date, the remote is the thing causing problems. We are currently testing a workaround, running rsync after each push. Since there are no dvc hooks (like there are git hooks), I do not see an elegant way of automating this.

[github-actions[bot]]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[sfc-gh-jrieke]

Hey, that's already supported with width="large", see the docs.

E.g. here's the large dialog:

Vs a standard dialog:

Or are you saying you want an even larger dialog?

[christian-heins-velero]

exactly, for example the option to cover a greater area, see in bigger screens or with greater resolutions the window remains very short and a great a mount of wider real estate is still available.

[LiShaoyu5]

Maybe it's better to keep keywords input and also accept numbers like: @st.experimental_dialog("dialog title", width=750) which is much more flexible and also uniform with the width parameter in other elements

[rhelouREV]

... or perhaps making the width argument a fraction of page width (e.g. width_ratio=0.8 to work on any device. Might also consider editing height in the same fashion.

[goelrishabh9]

Can this be accomodated in upcoming relase. The current maximum size of dialog box is very small for my requirement.

[goelrishabh9]

Can this be accomodated in upcoming relase. The current maximum size of dialog box is very small for my requirement.

@sfc-gh-jrieke @jrieke

[jrieke]

Hey all, it would really help if you could describe what exactly you want to put into the larger dialog. We also love screenshots or mocks if you have any! Then we can figure out which options we should add and how big they should be. I don't really want to allow arbitrary pixel numbers because a) it would make dialogs look very inconsistent across apps and b) it can quickly lead to problems, e.g. if devs make really large dialogs and then they cover the entire screen on a smaller device, which is not a great user experience.

[rhelouREV]

Hey all, it would really help if you could describe what exactly you want to put into the larger dialog. We also love screenshots or mocks if you have any! Then we can figure out which options we should add and how big they should be. I don't really want to allow arbitrary pixel numbers because a) it would make dialogs look very inconsistent across apps and b) it can quickly lead to problems, e.g. if devs make really large dialogs and then they cover the entire screen on a smaller device, which is not a great user experience.

@jrieke I suggest optional kwargs to specify percentage (not pixels) for width/height. As for the user experience, it would remain the responsibility of the the developer, but percentages should hopefully make it consistent. For example, if this were in a CSS style, it might be something like width: {width_percentage}% !important;

[christian-heins-velero]

Hi all,

i was thinking of creating profiles for example when i select a row trough the dataeditor i can display a profile of the row and control completly the information of that specific row. i was planning on adding a gallery, tables, metrics, buttons, creating the option to edit the record that was selected initiallly.

Thats why i want a bigger dialog box, to be able to display a adjustable (big, bigger) interactive window.

The thing to consider on smaller resolution windows the appearence might be good or in accordance to the smaller windows e.g. a laptop, but in higher resolution screens like the one i posted initially theres still a lot of free space.

[dasmy]

Also working on a dialog that requires some extended width due to complex content with multiple columns (to avoid using too much vertical space / produce a scrolling dialog), I came across this "solution":

st.write("""<style>
.stDialog *[role="dialog"] {
    width: 75%;
}
</style>""",
   unsafe_allow_html=True,
)

Note, that this relies on the current HTML structure generated by Streamlit which might change with upcoming releases. Also, the change applies to all dialogs in the app (not a problem for me as I only have one). I assume it should be possible to make it more selective, though (e.g. by adding a div with a unique class inside the dialog and then traversing to its parents with role=dialog).

[christian-heins-velero]

@dasmy thanks for providing this workaround, works like a charm, and i can call it on specific pages.

[kmprasad4u]

@dasmy , place the code you have inside the dialog and it will be used only when the dialog is open.

But I would also agree there should be a simpler solution as a property in the dialog itself with options for both percentage and fixed widths

[AFTownsend]

Just advocating my support for the ability to make the dialog wider. I think allowing width to take either "small" and "large" keywords or a percentage of the view port is a good solution

[wyattscarpenter]

I don't know about everyone else, but in my case, I am trying to put a very wide error message into the dialog box, which makes me think I'd like a bigger one. As big as possible, in fact.

The UI flow of a dialog is great for this, but the fact that it only takes up the middle half of the screen real estate is sub-optimal.

I mean, it's also somewhat silly that the error message I'm displaying comes to me with an ascii-art monospace text arrow as a key debugging feature, but, given that it does, I have to keep displaying it this way 😅

[lukasmasuch]

Update

We updated the width options for st.dialog to small (500px), medium (750px), and large (1280px). This will be released in 1.49.