Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Modular model VS all-in-one #154

Open
GoogleCodeExporter opened this issue Apr 18, 2015 · 16 comments
Open

Modular model VS all-in-one #154

GoogleCodeExporter opened this issue Apr 18, 2015 · 16 comments
Labels
auto-migrated Priority-High Type-Defect

Comments

@GoogleCodeExporter
Copy link 

since r930 it's now possible to use txt2tags with targets modules. 

It was a request from potential developpers (see, in French, 
http://linuxfr.org/news/sortie-de-txt2tags-26#comment-1179347 ), and it's 
probably easier for current developpers to work on it. It's also "cleaner".

But will it ever be as easy as before for users?

I mean, we only had to handle one python script, so it wasn't possible to 
forget a subfolder and such.

Would it be possible in the future to propose a way for users to create a kind 
of self containing python file with all the files included in it? (like 
phpcompiler can do).

Or at least to keep the html export build-in into txt2tags, with other modules 
not mandatory if they are not present.

Original issue reported on code.google.com by eforg...@gmail.com on 6 Jul 2012 at 6:36
@GoogleCodeExporter
Copy link
Author 

Currently the problem doesn't really exist.
For txt2tags, the target plugin system is in more of the regular targets.
Txt2tagslite, with no target inside it, is an experimental proof of concept.
For txt2tags, if you don't have the aa.py and spread.py libraries I have 
extracted from, all the targets that don't use this libs are perfectly usable.

Original comment by fgalla...@gmail.com on 7 Jul 2012 at 1:40

@GoogleCodeExporter
Copy link
Author 

Since r979 txt2tags no longer needs the targets directory to work.

Original comment by fgalla...@gmail.com on 16 Jul 2012 at 11:46

@GoogleCodeExporter
Copy link
Author 

I have another software (funcoeszz) that shares the same problem. It begun as a 
all-in-one script and after years of growing, I've split the script in tiny 
little files. Advanced users like it split, others like it as all-in-one.

The solution was to create a script that joins all the pieces back into one 
file. There's even a webapp where you can choose exactly which parts to join, 
making a custom package. See http://funcoeszz.net/a-la-carte/.

I think we can build something similar to txt2tags. The SVN will contain only 
the actual txt2tagslite file, and a new script could generate the txt2tags 
(all-in-one) file. We can also make it flexible to choose exactly which targets 
it should embed.

Oh, the current txt2tags website hosting server (DreamHost) allows to execute 
Python scripts, or use Python as the web language (opposed to PHP). Something 
very neat can be built around it for txt2tags.

Original comment by aureliojargas@gmail.com on 26 Jul 2012 at 3:17

  • Added labels: Priority-High, Type-Enhancement
  • Removed labels: Priority-Medium, Type-Other

@GoogleCodeExporter
Copy link
Author 

txt2tagslite + all required libraries = txt2tags (in a single file) would be 
the best to have in my opinion.

Being able to choose what to embed could be interesting too, but personnaly I 
don't really care if the resulting txt2tags would be 125 kb or 800 kb. On the 
other hand, one advantage to embed only some targets would be it could be 
easier for some users to focus on what they really need (txt2tags --targets 
would only return valid targets)

If possible, if an official target was not embeded but exists in txt2tags 
repository, calling this target could return something like
"spip target not present in this incantation of txt2tags", instead of "error,  
Invalid target"), so people would be aware of its existance.

Original comment by eforg...@gmail.com on 26 Jul 2012 at 7:54

@GoogleCodeExporter
Copy link
Author 

Currently, the main script is broken if the 'lib' folder is not found. See 
comments in r980.

Original comment by aureliojargas@gmail.com on 27 Jul 2012 at 6:54

  • Changed state: Accepted
  • Added labels: Type-Defect
  • Removed labels: Type-Enhancement

@GoogleCodeExporter
Copy link
Author 

Today I've tried to embed the modules in a single script, with no success. Not 
sure if it's really worth the trouble. Maybe it's time to think forward and go 
Lite only?

Original comment by aureliojargas@gmail.com on 28 Jul 2012 at 12:45

@GoogleCodeExporter
Copy link
Author

Original comment by aureliojargas@gmail.com on 30 Jul 2012 at 3:10

  • Changed title: Modular model VS all-in-one

@GoogleCodeExporter
Copy link
Author 

I think we can keep only the txt2tagslite in the repository, but it'd be really 
conveniant to be able to (automatically) export to a single script for end 
users.

Original comment by eforg...@gmail.com on 30 Jul 2012 at 3:27

@GoogleCodeExporter
Copy link
Author 

Florent, for the 2.7 release, we need to solve the /lib issue. There shouldn't 
be a /lib in v2.7, it will continue to be a all-in-one script. After that, we 
will use the new model and work towards v3.0.

You could undo the /lib separation in txt2tags or we can exclude the targets 
that need it for the release. I prefer the 1st option.

Original comment by aureliojargas@gmail.com on 30 Jul 2012 at 4:13

@GoogleCodeExporter
Copy link
Author 

For me the 'lib issue' is simple : txt2tags should work fine without the lib 
folder, but you just don't have the targets lib dependent, i.e. the Ascii Art + 
rst (aa.py) and Spread engine (spread.py) targets.
Just have to fix the txt target, which is using the aa.wrap CJK friendly 
wrapping.

Original comment by fgalla...@gmail.com on 30 Jul 2012 at 4:23

@GoogleCodeExporter
Copy link
Author 

I don't think many people require a single script, the modular version should 
be fine for most users. We just have to make sure installation is trivial, so 
the following should work (see issue58):

pip install txt2tags

Original comment by jendriks...@gmail.com on 30 Jul 2012 at 7:34

@GoogleCodeExporter
Copy link
Author 

Is the txt2tagslite code supposed to work at the moment?

All I get is:

python2 txt2tagslite -t html samples/sample.t2t 
txt2tags: Error: Invalid target 'html'

Run 'txt2tags --targets' to see all the available targets.


python2 txt2tagslite --targets

WIKI:

TEXT:

HTML:

OFFICE:


Anyway, I can read there:
http://www.evanjones.ca/software/packagepy.html

"How do you distribute the script and all the modules? I think the easiest 
answer is to package them into a single file. It turns out that Python supports 
executing .zip archives", so if it's possible to run txt2tags from a zip file, 
it should be enough.

Original comment by eforg...@gmail.com on 30 Jul 2012 at 7:47

@GoogleCodeExporter
Copy link
Author 

Yes, uncomment TARGETS_LIST in targets/config.py

Original comment by fgalla...@gmail.com on 30 Jul 2012 at 8:25

@jendrikseipp
Copy link

In my opinion it is almost irrelevant whether the code lives in one file or multiple files. The only thing that is important is that code for one target is separated from code for other targets. The separation should come from using a separate class for each target. Optionally, we can discuss if each class should live in its own file.

Currently, the code is a mix of general translation code and target-specific code à la "if target == 'tex': do-tex-specific things". We have to separate the txt2tags core from the target-specific code. The ultimate goal for the modularization has to be that there are no occurences of "if target == 'XXX'". Once this is the case, devs can add support for a new target without having to read and understand code for other targets. Also, we will be able to maintain the core without having to read code for specific targets.

txt2tagslite has made some steps in the right direction. It moved data for targets out of the core. The next step is to move code out of the core. One possibility for achieving this is to create an abstract base class Target from which all targets inherit (e.g., LatexTarget(Target)). Then the core just stores a Target object (self.target = LatexTarget(self.config)) and delegates all target specific calls to it, e.g., self.target.escape(txt) or self.target.create_header(headers).

@farvardin
Copy link
Contributor

I also noticed all the targets are imported during run-time. It means if users want to remove targets from the targets folder because they don't use them at all, it will raise an error like:

import targets
File "/###/targets/init.py", line 54, in
exec('import ' + target)
File "", line 1, in
ImportError: No module named rst

isn't it possible to import them dynamically, i.e. if they don't exist they are not imported, and if there is a new one it will be imported, without touching the core code?

@fgallaire
Copy link
Member

@farvardin there is a file named config.py and inside it a variable named TARGETS_LIST, it can't be simpler...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Priority-High Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fgallaire @jendrikseipp @farvardin @GoogleCodeExporter