Update lib docs

[christopher-hakkaart]

• Add -lib in lib sharing section
• Add Custom lib directory section to cli users section

cc @robsyme

[netlify]

✅ Deploy Preview for nextflow-docs-staging ready!

Name	Link
🔨 Latest commit	fe65e0a
🔍 Latest deploy log	https://app.netlify.com/sites/nextflow-docs-staging/deploys/67332e6cbf314500089a9e2e
😎 Deploy Preview	https://deploy-preview-5492--nextflow-docs-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[robsyme]

I think that the lib directory wording could be more precise.

Any Groovy scripts or JAR files in the lib directory in the project directory root will be available inside the Nextflow workflow automatically.

The "Any Groovy scripts" feels a bit too loosely defined. The directory is added to the classpath, which means that any classes or packages defined therein will be available in the execution context. Loose scripts, or functions defined outside of classes will not be available to Nextflow.

You can load arbitrary assets in this lib directory with classLoader.getResource:

workflow {
    def myFile = this.class.classLoader.getResource("my-file.txt")
    println = myFile?.text
}

But imho, this should be discouraged. It should be used for loading classes and packages only, and the documentation should encourage this by making it explicit that the lib directory is to be used to make classes and packages available in the workflow.

[robsyme]

@pditommaso has also noted internally that the -lib CLI argument encourages bad practice and is likely going to be deprecated, so any documentation addition would be best focused on documenting the lib directory (which will be retained).

[christopher-hakkaart]

All good. I've converted this PR to a draft and re-work it to focus on documenting best practises for the lib directory.

[robsyme]

Potential example:

// lib/DNASequence.groovy
class DNASequence {
    String sequence

    // Constructor
    DNASequence(String sequence) {
        this.sequence = sequence.toUpperCase() // Ensure sequence is in uppercase for consistency
    }

    // Method to calculate melting temperature using the Wallace rule
    double getMeltingTemperature() {
        int gCount = sequence.count('G')
        int cCount = sequence.count('C')
        int aCount = sequence.count('A')
        int tCount = sequence.count('T')

        // Wallace rule calculation
        double tm = 4 * (gCount + cCount) + 2 * (aCount + tCount)
        return tm
    }

    String toString() {
        return "DNA[$sequence]"
    }
}

// main.nf
workflow {
    Channel.of('ACGTTGCAATGCCGTA', 'GCGTACGGTACGTTAC')
    .map { seq -> new DNASequence(seq) }
    .view { dna -> 
        def meltTemp = dna.getMeltingTemperature()
        "Found sequence '$dna' with melting temperaure ${meltTemp}°C" 
    }
}

Which returns

Found sequence 'DNA[ACGTTGCAATGCCGTA]' with melting temperaure 48.0°C
Found sequence 'DNA[GCGTACGGTACGTTAC]' with melting temperaure 50.0°C

[christopher-hakkaart]

Thanks for the example. I've updated the PR with the example and a revised lib section.

The sentence "Scripts or functions defined outside of classes will not be available in the execution context." could be made into a warning either before or after the example if you think it should be more prominent.

[pditommaso]

but hard to read those variables maybe g_count or gc is a better alternative

[christopher-hakkaart]

Suggested change

	int gCount = sequence.count('G')
	int cCount = sequence.count('C')
	int aCount = sequence.count('A')
	int tCount = sequence.count('T')
	// Wallace rule calculation
	double tm = 4 * (gCount + cCount) + 2 * (aCount + tCount)
	int g_count = sequence.count('G')
	int c_count = sequence.count('C')
	int a_count = sequence.count('A')
	int t_count = sequence.count('T')
	// Wallace rule calculation
	double tm = 4 * (g_count + c_count) + 2 * (a_count + t_count)

@robsyme does this work for you?