Why do Lazarus users share code via zip files rather than repo links?

[vfclists]

The title says it all.

My point is you don't always want to run examples, you often just want to see the code, then download and run it if you want to go further.

OK - why not both? If the link becomes outdated the file will be somewhere on this forum for posterity.

Before repos become popular that was the normal way to share code even if it was just to view it. But in this era of free repo hosting where code can be easily read online this option should be considered by forum users.

Of course not everyone has the fast internet or the bandwidth that makes viewing code online easy, so the download option must remain for others. Even the repos hosters offer the ability to download the repos as archives.

I don't frequent other forums that much, but is this the norm in the Delphi/FreePascal world?

[440bx]

I would not use a repo because using the repo in a way promotes the repo.

I'd much rather attach the code to a post in this forum.  That way, if someone wants the code (or just look at it) they'll have to come HERE, be exposed to Lazarus and FPC, that is the reason why I will not place any code in a repo.

All that said, I understand there is a cost associated with hosting attachments, I hope it's low.

[KodeZwerg]

Creating a repo that does not contain a real app, it contain a help for a specific topic, where is that topic, ah on this forum, so why split?

[cpicanco]

I think that people will share by means that fits best their current knowledge, or available time, their preferences, conveniences. Personally, I like the freedom you have here in the forum. Sometimes, pseudocode is all you need to get stuff done. You known what I mean??

Also, I fully agree. People should get used to come here, not going out there. I have a repository and you will find me making some effort to write code here instead.

[Thaddy]

A zipped project from somebody that needs/asks help is a better way to help us assess the code that does not belong in a repo yet. Otherwise we get repo-rot. That is already a problem. Bots will find such unfinished or plainly wrong code and that makes maintaining a high quality code base for Pascal more difficult on a global scale.
I prefer this order:
Code snippet here
Complete basic example here, which is often the best solution.
A zip file with a project that needs attention
A well thought out project in an online repo.

[MarkMLl]

It's a community convention, that's why.

The reason it's a community convention is that it does not rely on an external server which might become (permanently or otherwise) unavailable, or might have the files or user removed (e.g. at the end of an academic year). Either of those scenarios would cause major problems for anybody who arrived here at some later point because he had a similar problem.

In addition, having the file attached prevents the community having to rely on a service which might start hosting intrusive advertising (as happened to Sourceforge at one point) or might decide that it will block users from countries on the USA's shitlist (again, Sourceforge).

It guarantees that the files are in a very specific state, and does so without the risk that the user will find himself transferring the entire history of what might be a long-running project with a large number of  updates (a particular problem with anything Git-based).

Finally, a .zip file can be read by just about any operating system, unlike .rar (historically, poor support on unix) or .tar.gz (historically, poor support on Windows).

MarkMLl

[domasz]

I kinda feel Github makes more sense for working, complete projects while in ZIP I can share just a single unit, a broken project, half-baked things. I also like the fact ZIP files stay for years while many Github repos I watched are already gone.

[JuhaManninen]

Finally, a .zip file can be read by just about any operating system, unlike .rar (historically, poor support on unix) or .tar.gz (historically, poor support on Windows).

That is part of history. Nowadays Linux distros and desktops support all compression formats. For example my Ark (part of KDE) shows a huge list of formats.
AFAIK many Windows compression apps also have good support.

It means that ideally files uploaded here should be compressed with a more efficient format than .zip.
In some cases it may prevent the attachment size limit hitting. It also has a positive effect on people with limited bandwidth.

[domasz]

Finally, a .zip file can be read by just about any operating system, unlike .rar (historically, poor support on unix) or .tar.gz (historically, poor support on Windows).

That is part of history. Nowadays Linux distros and desktops support all compression formats.

RAR is still problematic because its license makes it illegal to create a program which can pack files to RAR. So you can only unpack or create uncompressed RAR archives.

[vfclists]

A point I want to  make is that not all code hosted by repos have to be full sized repos, some are just gists and some are just links to directories with the code stored in the subdirectories.

By all means have the zipped project here on this forum, but a link to the hosting website could be added as well. If the link rots, the zip file is still here, and if lucky the internet archive may have the link directories if they are plain text, HTML, including the zips.

Another option is shallow clones or clones of a specific commit. These don't entail downloading the whole repo, just a specific commit or a specific branch.

In my case for instance every I have created an examples directory where I unzip the files to view them. This entails copying the link, opening a console, navigating to the examples directory, and using git clone/wget/curl to download the file.

We could have custom protocols to automate the whole process.

It all boils down to making it convenient for the viewer to minimize the effort for the reason that not everyone has the means or time to go all the way to examine ones code unless they actually need it.

Take this long running link by JPF12141999, I am positive that some of the errors could be caught by inspecting the code alone, without an interested party  having to download 300Mb of Castle Engine libraries to see what could be wrong.

Languages developed in the post internet era have the jsfiddles, phpfiddles, sandboxes etc which allow quick examination and testing. FreePascal limits itself because the approach narrows the pools of individuals able to help to those with the time, ready prepared IDEs, and a willingness to dive in and compile code, when a simple code review on a gist or repo browser would probably catch the errors.

My opinion is that it is up to the person making the post to provide both the links and the zip files. They are the one making the request and they are one who needs to make the effort to broaden the pool of willing helpers.

[Martin_fr]

Before repos become popular that was the normal way to share code even if it was just to view it. But in this era of free repo hosting where code can be easily read online this option should be considered by forum users.

Well, there are no guidelines... So the answer is, those that use zip do that by personal choice.

But, it actually has some positive sides to it too (not the zip, but attachment versus link to repo):
A link to an other side, is loosely coupled. If the forum post is read some month after it was made it is not clear (or more work) to determine if the external content is still in the state it used to be when the question was made. It is likely answers will be added based on that mismatch.
Of course the user making the post can edit the post too, but then they are aware, and likely to also update the question. In comparison if the update their repo, they may not thing of adding a note to their forum post.
And yes, if correctly done, it can all be avoided. But it still means that the reader(s) of the post now all have to put in the effort of evaluating that it was correctly done.

To be absolutely clear: Mistakes can happen with both scenarios.  I am comparing likelihoods.

Then again, if a user wants to make it easier for their readers, they can always inline the important parts of their attachment using [ code ] tags. One would expect that to attract more answers, and then yes it leaves the questions why some users don't.

[KodeZwerg]

Finally, a .zip file can be read by just about any operating system, unlike .rar (historically, poor support on unix) or .tar.gz (historically, poor support on Windows).

That is part of history. Nowadays Linux distros and desktops support all compression formats. For example my Ark (part of KDE) shows a huge list of formats.
AFAIK many Windows compression apps also have good support.

It means that ideally files uploaded here should be compressed with a more efficient format than .zip.
In some cases it may prevent the attachment size limit hitting. It also has a positive effect on people with limited bandwidth.

In past, when I did used 7z users wrote that they cannot handle that format, what is in your opinion a better than zip and compatible to all format?

[MarkMLl]

Finally, a .zip file can be read by just about any operating system, unlike .rar (historically, poor support on unix) or .tar.gz (historically, poor support on Windows).

That is part of history. Nowadays Linux distros and desktops support all compression formats. For example my Ark (part of KDE) shows a huge list of formats.
AFAIK many Windows compression apps also have good support.

It means that ideally files uploaded here should be compressed with a more efficient format than .zip.
In some cases it may prevent the attachment size limit hitting. It also has a positive effect on people with limited bandwidth.

That depends on the correct decompression program or library being installed by the distro: Ark is by no means infallible in its specification of prerequisites and neither (as an aside) are things like binwalk.

Also I'm not sure if it's still the case, but until fairly recently there were versions of the .rar archive that could not be handled by the free (as in speech, i.e. sourcecode available etc.) utilities.

The .zip format, OTOH, is by now deeply embedded in most OS bundles as a prerequisite of compressed XML files, not to mention other bundles including .jar files. So let's all hoist a coffee in memory of Phil Katz :-/

MarkMLl

[TRon]

Also I'm not sure if it's still the case, but until fairly recently there were versions of the .rar archive that could not be handled by the free (as in speech, i.e. sourcecode available etc.) utilities.

afaik this is still the case. I need to use/activate non-free ports in order for these to install. They still exist therefor I assume....

[Thaddy]

password protected.