Firstly, thanks for developing this as open source software and secondly thanks for thinking about releasing it via CPAN. Thirdly, thanks for asking about doing so first. :-)

Should I prepare to upload under the App: namespace upload under LSeismic_Unix-0.7_6 or is this mixed-language project not appropriate for uploading to CPAN.

Personally, I think mixed-language projects are fine for uploading to CPAN. If your code is more of an app than a module then, yes, as release under App::* would perhaps be more appropriate. Note that otherwise your preferred name would mean creating a new top-level namespace in CPAN and that really is frowned upon unless you have a very good reason for doing so. Also, I would suggest you use the N.NN_NN version naming system, ie. 0.07_06 in this case as that is what both users and the toolchain components will most likely expect.

I have chosen the name carefully and a quick google search shows that it can be directly related to a C-based open-source application (Seismic Unix) that it needs to function. ("L" stands for Louisiana).

Would anyone know that L stands for Louisiana? Would anyone know what Louisiana means in the context of this module?

PAUSE suggested I contact PrePAN users for advice but I have not been able to enter their site effectively.

That is a concern. I see no new modules added to PrePAN in the last 11 months. As a github user you should have easy access. If you can explain what is preventing you from posting there we might be able to help with that (or suggest who could).

Update: It is now the 15th of September 2022 and the PrePAN has gone. The domain has been taken by someone else and is now unrelated to Perl. :-(

Thanks to hippo and Grandfather both for your support and advice!

A. PrePAN issue: When I use my github account to log in (successful) to the site, I see the following error message: Authentication Failed 400 Bad Request

B. I will consider uploading as App:SeismicUnixGui, after I check with providers of SeismicUnix (open-source)

Thanks, gllore

Note that otherwise your preferred name would mean creating a new top-level namespace in CPAN and that really is frowned upon unless you have a very good reason for doing so

its enthusiastically allowed

existing code is an especially good reason

lots of naming advice out there, feel free to ignore all of it :D

Re: Module name: PDL::WebSocket? (No. ), Re: RFC: Automatic logger module

If you upload it as a module the user can use the key module as a module or a script if you add:

return 1 if caller;

...
[download]

to the end of your module. The caller line returns true as required for a module to load correctly. When run as a script caller returns false and the following code is executed.

That maybe helps as part of a technical solution, but doesn't address the more philosophical component of your question. For that I'm sorry I have no good advice, except that I don't see the harm in providing such a system as a module on CPAN.

For example, https://github.com/gllore/App-SeismicUnixGui/blob/0.70_60/lib/App/SeismicUnixGui/geopsy/dinver.pm has package dinver;. This will claim the top-level package "dinver".

Thanks etj

For example, would the following solution keep a lower-cased package at its corresponding low level?

package App::SeismicUnix::geopsy::dinver;

That would be a very idiomatic and good solution.

Zooming out a bit - I happened to notice that you have another repo which looks like the actual place where the real code lives. Is there a reason not to add the extra CPAN-able stuff to it rather than have this separate repo?

Thanks again for that last note

Yes, many fine examples

already exist in the CPAN e.g., PDL itself

        'PDL::Core'       => '2.028',
[download]

        'PDL' => '2.080',
[download]

                url  =>
                  'git://github.com/Perl-Toolchain-Gang/ExtUtils-MakeM
+aker.git',
                web =>
                  'https://github.com/Perl-Toolchain-Gang/ExtUtils-Mak
+eMaker',
[download]

Finally, it looks like your lib/App/README.md would be far more useful at the top level :-)

The further thought I have is that you might benefit from structuring your code in a more CPAN-like way; specifically, to move your current code more to being a set of libraries, that your application (or possibly, applications) can call to achieve their effects. This would include separating out your actual seismic stuff (which I assume uses PDL) into truly separate modules, that could be released separately. You would also carve out any Tk widgets that are genuinely separate, if you have any rather than "just" a nice Tk user-interface.

The general approach would be to turn what is currently a large, impressive piece of code that I am sure is really useful in exactly its current context (in classrooms, if I got that right), into a number of smaller pieces of code assembled into something great for that context, but allowing many other uses too. For instance, I would quite like to make a PDL demo out of the seismic stuff, with visualisations using either Gnuplot (like Photonic uses), or maybe OpenGL (using PDL's "TriD" stuff).

Specific thoughts on handling C code. If it can be carved out into its own Perl-accessible XS code, you should do that. EUMM handles that just by adding to the OBJECT key/variable. If you have C code that is useful to link into a number of bits of XS code, then you can copy the model used in the partly-finished https://github.com/PDLPorters/PDL-OpenCV: it creates .o files in the top directory (in fact, out of autogenerated C code), then the subdirectories' Makefile.PLs add those .o files to be linked into that subdirectory's library. If you just have C executables like synseis, then PDL's pdl.c shows how to build and install those. However, looking at that code, it might well be better as a Perl script with an XS library for the various functions like ricker, and maybe even just use PDL for those.

Thanks for all your suggestions. I've been working (silently)

and incorporating everyone's suggestions

Your overview is excellent and I will try to carve out additional Tk subtools

Currently, I agree that SeismicUnixGui is rather monolithic, single-purposed and needs a lot

of work to break it down into sets of libraries .

There are however about 10 Tk "tools" that can be run independently of the main GUI

Currently, PDL is very useful for handling image data that feeds into one of these detachable Tk "tools"

This Tk tool messages interactively with fortran code which pipes data out to pgplot

I must say that the Monks have been very encouraging and enlightening

Thanks

Thank you for the kind words!

I wonder if the Fortran code might be easier to work with if it were brought more under Perl control by making it a library callable from XS, and/or making it a PDL library? Then you'd be able to just call pgplot commands from Perl and maybe even avoid having to do that by throwing PDL data structures to Fortran to be worked on, then to PDL::Graphics::PGPLOT?

Anyway, good luck with your ongoing work. It sounds very interesting!

Thank you for catching that. Shows my ignorance! I will work on creating an extra dist_dir after CAREFUL reading of the File::ShareDir/File::ShareDir::Install

gllore

Thank you for that tip!

I studied and tested cases for File::ShareDir

I have learnt to use File::ShareDir to find "auto" directory post installation

But I can not figure out how provide "auto" directory to MakeMaker

Can I make the post-installation scripts installed in "auto"

run automatically via MakeMaker. Your way would definitely be cleaner

Thanks in advance for your advice gllore